Dotaz: JFS + externy disk - poskodzovanie filesystemu

[andree]

Zdravim,

mam taky problem, s ktorym si neviem uz dlhsie poradit. Resp. poradit ano, ale neviem sa ho uplne zbavit.

Problem je v tom, ze mam externy usb disk a na nom JFS filesystem. Pri kazdom uspavani sa vykona toto:

umount /media/disk


sync; sync; sync

Problem je ale v tom, ze ked sa ho pokusim neskor znovu pripojit, je potrebne vykonat fsck /dev/disk, inak mu furt nieco vadi.. Vacsinu casu to nie je problem - pri fsck sa len prehra journal a je pokoj. Dnes sa ale journal neprehral, miesto toho sa spustila standardna kontrola a par giga dat (nastastie tam mam "len" nedolezite data a zalohy) slo do lost+found (samozrejme pod divnymi nazvami atd., takze v podstate su to uz nepouzitelne veci...).

Nie je divne ze aj po umount + 3x sync ostane ten disk v nekonzistentom stave?

Mna teda napada ako mozny zdroj problemov len to, ze ten disk je kus blby a nezapisuje data, ked ma ale drzi si ich pridlho v cache. A mam pocit ze cez USB mu neprikazem, ze uz to ma flushnut...

Druha moznost je ze niekto v ubuntu teame ten JFS pekne zmrsil - ale to sa mi az nechce verit, ze je to mozne.

Stretol (a vyriesil) sa niekto z vas s takymto niecim?

Odpovědi

[Petr Šobáň]

A jak ten disk napájíš ? Neodpojí PC dřív napájení než ten disk zapíše fyzicky ty data na plotny?

 

Co se stane když provedeš umount ručně, a počkáš třeba 1minutu a potom dáš Pc uspat ? Taky to poničí data ?

[petr]

Neměl bys nejprve pustit ten sync, aby se data z RAM uložila na disk(y), a teprve potom umount?

[andree]

toto by problem nemal byt - umount snad nezabuda, ze ma nieco ulozit na disk :)

[andree]

no to je prave jedna z tych moznosti - skusil som teraz taku vec, ze za sync dat este dd if=/dev/sdc of=/dev/null bs=1M count=100 iflags=direct - tak uvidime, ci sa nieco zmeni.. mozno to disku pomoze, aby sa flushol..

on je totiz pripojeny externe v USB sufliku.. keby to rozhranie usb-disk nebolo tak blbo navrhnute, mohlo by sa pouzit hdparm -W 0 a bolo by po problemoch no...

[sekyt]

No já bych k tomu řekl tohle ...

Na Debianu (Etch, posléze Lenny i chvilkově Sid) jsem cca rok jako FS používal JFS.
Bez nějakých problémů.

Pak jsem loni na podzim zkoušel Kubuntu 8.10 a protože se mi nechtěla dělat instalaci a chtěl distro s KDE 4 pořádně omakat, nechával jsem cd v nb a ten uspával do ram (v podstatě několik dnů po sobě) ... pohoda.
Jenže, pak najednou nešly partišny s JFS po probuzení připojit - nastala pocopitelně panika, pak fsck /dev/disk ... opravilo se ... jen po dalším uspání jak přes kopírák to samé ... z nainstalovaného Debianu to pochopitelně taky nefakčilo.

To samé se při testování opakovalo před pár dny s Kubuntu 9.04 po uspání (instalace na hdd) a použítí JFS jako fs pro /.
Takže asi tak.

Ale třeba je to rukama .

[andree]

prave teraz mam podozrenie skor na hw problem - ale mozno tomu debianu dam sancu :))

[sekyt]

Já už JFS & *buntu nevěřím, tudíž tahle kombinace je u mne ee

[Ivan]

Kdysi mel linux kernel problem v tim, ze presne nebylo jasny co znamena, ze data byla zapsana na disk. V nekterych pripadech byla data povazovana za zapsana i v pripade, ze je pouze prijala hw cache primo na disku. Zajimavy na tom bylo, ze tahle chyba vadila nekterym zurnalovacim systemum vice a jinym mene. Pokud se dobre pamatuju, tak se dlouho hledala chyba v XFS. Mozna ze mas podobny problem - zkus hledat mezi parametry hdparmu, taky je mozny, ze ten tvuj USB ramecek proste nektery ATA commandy nepropousti.

 

[andree]

no, tak teraz som zapol stroj po uspani a snad prvykrat neprebehol fsck s tym ze teda volam pred uspanim ten horeuvedeny "dd prikaz", vdaka comu sa zrejme vyprazdnila cache...

uvidim, ci to bude robit aj nabuduce - predpokladam ale, ze toto bude ten problem.. holt je ten USB ramcek blby :)