Ext3 - 4 a anomálie v Linuxe

13.3.2010 08:21 | Přečteno: 1693× | Hmmm | poslední úprava: 13.3.2010 09:41

Stáva sa Vám že z ničo ho nič sa systém spomalí a pri tom procesor je vyťažený na 50% alebo menej, prípadne sa zahlatí podivne na 100%, alebo nevysvetlitelné problémy s grafikou alebo iným HW, dokonca so softvérom ktorý na inom kompe maká? Stačí nepoužívať ext3, ext4, to čo som ja zistil pred rokmi, nedávno riešili vývojáry jadra a prišli na to čo ja že ext môže za nevysvetlitelné spomalenia a chyby jadra, je podivné že reiserFS ide out a ext4 je ako jednotka, ale napriek tomu skúste reiserFS a budete prekvapený a svoj komp nespoznáte, už som to písal viac krát v diskusiách o HW a chcel som to dať aj do blogu, tak aspoň teraz ako česť najlepšiemu (nielen)desktopovém FS všetkých čias. Je už dosť ľudí čo spokojne používajú reiser4, ale ten ešte nieje začlenený do hlavnej vetvy jadra, dúfam že sa toho niekedy dočkáme, alebo sa bude ďalej preferovať slimák ext. Teraz chvílu rozmýšlate či na tom môže byť niečo pravdy, stačí vyskúšať a môžete mi posielať ďakovné dopisy
       

Komentáře

[balevas]

Taketo fundovane zhodnotenie som necital uz davno. Vecna skoda, ze ti babraci co vyvijaju jadro si uz davno necitali tvoje diskusne prispevky, v ktorych si uz pred vekmi odhalil pravdu o filesystemoch v Linuxe. Asi je hlavny problem v tom, ze boli lenivi naucit sa poriadne po slovensky.

[Bedňa]

Kde píšem že sú babráci!!! Ja som napísal že preferujú ext, kurňa to fakt vždy musí niekto prekrúcať čo napíšem.

[poky74]

Jen bych se zeptal, pokud je pan Reiser ve vězení, kdo pokračuje ve vývoji?

[Bedňa]

Ako hovorím o reiserFS, tam každé zlepšenie je krokom späť

[Bedňa]

Toto je na wilipedii.

Although kernel developer Theodore Ts'o has suggested btrfs as an alternative for those interested in the design ideas of Reiser4,[15] Reiser4 development still continues,[16] delivering patches via kernel.org.[17]

In a mailing list post from July 2009, Edward Shishkin wrote that in the coming autumn, they would start exploring the opportunity of getting Reiser4 into the main Linux kernel.[18] In a November 2009 interview[19] to Phoronix he said he is going to publish plug-in design document for independent expert review. He is currently aiming for USENIX Annual 2010. If all goes well, Reiser4 may enter mainline Linux kernel around version 2.6.36.

[alblaho]

Vždycky když si někde přečtu, že "reiser4 _ještě_ nebyl začleněn do jádra", tak si říkám jací jsou lidi idealisti.

Reiser4 byl odmítnut jadernými vývojáři. Tečka.

[Bedňa]

To je teraz aj Android a ako Google tvrdí dostane ho tam späť, vývoj nezastavíš.

[Käyttäjä 11133]

Dostat zpět ho tam můžou, ale k tomu budou muset poslouchat námitky ostatních vývojářů a správců jednotlivých subsytémů, jinak budou vykopnuti znova. :)

[phr]

A ty námitky mají kvůli (ne)funkčnosti nebo kvůli tomu, že Reiser bručí ?

[vlastikroot]

AFAIK kvuli specifickému code stylu a taky nedostatečné udržovanosti.

[Michal Kubeček]

Co si vzpomínám, jsou tam i nějaké deadlocky, které vývojáři ReiserFS popírají a tvrdí, že jde jen o hypotetickou konstrukci.

[Käyttäjä 11133]

Co má Reiser co společného s odstraněním Googlích Android patchů z mainline kernelu? :)

[Heron]

Mohl bys dát odkaz do konferencí jádra a ext na příspěvky o tomto problému?

[Bedňa]

Nemôžem to nájsť, skúsim pohladať neskôr, samozrejme to nebolo napísané až tak drasticky ako som to opísal ja, ale vychádzam z vlastných skúseností, zatiaľ jediná stopa je neobvikle veľký počet bugov s ext3 a ext4 v changelogu pre 2.6.34-rc1. dokonca niekoľnásobný oproti zvyklosti, určite to ešte pohladám.

[Heron]

Nemôžem to nájsť, skúsim pohladať neskôr, samozrejme to nebolo napísané až tak drasticky ako som to opísal ja

Mailling listy ext4 a lkml pročítám celkem pravidelně a na nic takového jsem tam nenarazil, proto se na to ptám .

ale vychádzam z vlastných skúseností

To jde vidět. Ext je takový FS, který nenadchne a neurazí. Osobně svěřím data raději mnoho let prověřené ext3 (pokud nenarazím na limit velikosti FS) než systému, který se (z různých důvodů) nedostal do jádra a tudíž do pořádného testování na živých datech.

zatiaľ jediná stopa je neobvikle veľký počet bugov s ext3 a ext4 v changelogu pre 2.6.34-rc1

Mno. Raději bych si s kategorickými soudy počkal na prověřené stabilní jádro, než na rc.

[Martin Mareš]

Progrepnul jsem si changelog na "ext3". Výsledek: většina změn jsou cleanupy, pak jeden bugfix quoty, jeden bugfix race condition (kterou Honza Kára podle všeho objevil při čtení kódu a není jasné, jestli se někdy někomu projevila), jedna oprava reakce na hardwarovou chybu při zápisu na disk. To je opravdu vážné, což?

[Bedňa]

Hm, tak to máš asi bug v grepe, lebo toľko bugov a budfixov sa len tak nevidí, dovlím si povedať že je to rekord, spočítaj ext3 + ext4 až ich nieje 100 tak asi mám iný internet

[Martin Mareš]

Možná koukám do jiného changelogu? Mohu poprosit o link?

[Bedňa]

Tu.

[Lol Phirae]

Porad ty tvoje stovky bugu nevidim, myslim, ze chyba bude na tve strane nekde mezi zidli a monitorem.

[Martin Mareš]

mares@camellia:/tmp$ grep ext3 ChangeLog-2.6.34-rc1 
      ext3: add writepage sanity checks
      ext3: Truncate allocated blocks if direct IO write fails to update i_size
      ext3: quota_write cross block boundary behaviour
    ext3: add writepage sanity checks
    ext3: Truncate allocated blocks if direct IO write fails to update i_size
    ext3: quota_write cross block boundary behaviour
    But ext3_quota_write() function may handle cross block boundary writes
    ext3: trivial quota cleanup
    ext3: mount flags manipulation cleanup
    ext3: Use bitops to read/modify EXT3_I(inode)->i_state
    (ext3_release_file, ext3_bmap, ext3_journalled_writepage, ext3_do_update_inode,
          18.49%     +0.16%  [ext3]
           6.21%     +0.36%  [k] ext3fs_dirhash
           3.06%     +0.37%  [k] ext3_htree_store_dirent
           6.21%     +0.36%  [ext3]              [k] ext3fs_dirhash
           3.06%     +0.37%  [ext3]              [k] ext3_htree_store_dirent

Co najde grep Vám?

[Michal Kubeček]

Třeba to kolega grepoval na "ext"… :-)

[Bedňa]

Musím sa hanbiť, ale v robote mám Widle, tak som to pozeral len vizuálne a vyzeralo to ďaleko horšie Ale aj tak pripájam čo som nagrepoval ja, ext3 ani nedávam.

mario@s29:~/Plocha$ cat Change | grep ext4
    Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
    * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (36 commits)
      ext4: fix up rb_root initializations to use RB_ROOT
      ext4: Code cleanup for EXT4_IOC_MOVE_EXT ioctl
      ext4: Fix the NULL reference in double_down_write_data_sem()
      ext4: Fix insertion point of extent in mext_insert_across_blocks()
      ext4: consolidate in_range() definitions
      ext4: cleanup to use ext4_grp_offs_to_block()
      ext4: cleanup to use ext4_group_first_block_no()
      ext4: Release page references acquired in ext4_da_block_invalidatepages
      ext4: Fix ext4_quota_write cross block boundary behaviour
      ext4: Convert BUG_ON checks to use ext4_error() instead
      ext4: Use direct_IO_no_locking in ext4 dio read
      ext4: use ext4_get_block_write in buffer write
      ext4: mechanical rename some of the direct I/O get_block's identifiers
      ext4: make "offset" consistent in ext4_check_dir_entry()
      ext4: Handle non empty on-disk orphan link
      ext4: explicitly remove inode from orphan list after failed direct io
      ext4: fix error handling in migrate
      ext4: deprecate obsoleted mount options
      ext4: Fix fencepost error in chosing choosing group vs file preallocation.
    ext4: fix up rb_root initializations to use RB_ROOT
    ext4 uses rb_node = NULL; to zero rb_root at few places.  Using
    warnings with ext4 + quota and generally make life of some filesystems easier.
    ext4: Code cleanup for EXT4_IOC_MOVE_EXT ioctl
    a) Fix sparse warning in ext4_ioctl()
    ext4: Fix the NULL reference in double_down_write_data_sem()
    ext4_ioctl() gets inappropriate file structure for donor; so we need
    ext4: Fix insertion point of extent in mext_insert_across_blocks()
    ext4: consolidate in_range() definitions
    balloc.c.  This consolidates these two definitions into ext4.h, and
    ext4: cleanup to use ext4_grp_offs_to_block()
    number of a free extent to use ext4_grp_offs_to_block() instead.
    ext4: cleanup to use ext4_group_first_block_no()
    converts them to use the (already defined) ext4_group_first_block_no()
    ext4: Release page references acquired in ext4_da_block_invalidatepages
    ext4_da_block_invalidatepages.  Luckily, this function gets called only if we
    Get rid of mnt_mountpoint abuses in ext4
    ext4: Fix ext4_quota_write cross block boundary behaviour
    But ext4_quota_write() function may handle cross block boundary writes
    ext4: Convert BUG_ON checks to use ext4_error() instead
    Convert a bunch of BUG_ONs to emit a ext4_error() message and return
    ext4: Use direct_IO_no_locking in ext4 dio read
    ext4: use ext4_get_block_write in buffer write
    Allocate uninitialized extent before ext4 buffer write and
    we can safely drop the i_mutex lock in ext4 DIO read without
    ext4: mechanical rename some of the direct I/O get_block's identifiers
    and fallocate" patches so that they can be used by ext4's buffered
    ext4: make "offset" consistent in ext4_check_dir_entry()
    The callers of ext4_check_dir_entry() usually pass in the "file
    offset" (ext4_readdir, htree_dirblock_to_tree, search_dirblock,
    ext4_dx_find_entry, empty_dir), but a few callers (add_dirent_to_buf,
    ext4_delete_entry) only pass in the buffer offset.
    this patch changes ext4_check_dir_entry() to print the physical block
    ext4: Handle non empty on-disk orphan link
    ext4: explicitly remove inode from orphan list after failed direct io
    ext4: fix error handling in migrate
    ext4: deprecate obsoleted mount options
    ext4: Fix fencepost error in chosing choosing group vs file preallocation.
    The ext4 multiblock allocator decides whether to use group or file
    mkfs.ext4 -b 1024 /dev/sda8 1000000
    mount -t ext4 -o nodelalloc /dev/sda8 /mnt/ext4
    cat /mnt/4096>>/mnt/ext4/a	#4096 is a file with 4096 characters.
    cat /mnt/4096>>/mnt/ext4/b
    ext4_mb_group_or_file, but in ext4_mb_normalize_request, we meet with
    This patch just change the check in ext4_mb_group_or_file, so
    ext4: trivial quota cleanup
    ext4: mount flags manipulation cleanup
    ext4: Add flag to files with blocks intentionally past EOF
    ext4: Fix BUG_ON at fs/buffer.c:652 in no journal mode
    Calls to ext4_handle_dirty_metadata should only pass in an inode
    ext4: correctly calculate number of blocks for fiemap
    ext4_fiemap() rounds the length of the requested range down to
    ext4: add missing error checking to ext4_expand_extra_isize_ea()
    ext4: move __func__ into a macro for ext4_warning, ext4_error
    ext4: Reserve INCOMPAT_EA_INODE and INCOMPAT_DIRDATA feature codepoints
    ext4: Use bitops to read/modify EXT4_I(inode)->i_state
    i_mutex (ext4_release_file, ext4_bmap, ext4_journalled_writepage,
    ext4_do_update_inode, ...). These modifications are racy and we can
         1.35%             find  [kernel.kallsyms]                  [k] ext4_check_dir_entry
         1.35%             find  [kernel.kallsyms]                  [k] ext4_htree_store_dirent
    ext4: Use slab allocator for sub-page sized allocations
    ext4: Add new tracepoints to debug delayed allocation space functions
    Add tracepoints for ext4_da_reserve_space(),
    ext4_da_update_reserve_space(), and ext4_da_release_space().
    ext4: Add new tracepoint for jbd2_cleanup_journal_tail
    ext4: Add block validity check when truncating indirect block mapped inodes
    Add checks to ext4_free_branches() to make sure a block number found
    ext4_free_branches() could end up zero'ing out a block group
    read in by ext4_read_block_bitmap().  This function calls
    ext4_valid_block_bitmap(), which assumes that bg_inode_table() was
    (ext4_inode_table(sb, desc) - group_first_block) to go negative, which
    will cause ext4_find_next_zero_bit() to trigger a kernel GPF.
    ext4: Fix optional-arg mount options
    may not take a 1/0 argument.  This causes the ext4 superblock mount
    ext4: fix async i/o writes beyond 4GB to a sparse file
    The "offset" member in ext4_io_end holds bytes, not blocks, so
    ext4_lblk_t is wrong - and too small (u32).
    Also fix up the type of arguments to ext4_convert_unwritten_extents(),
    it gets ssize_t from ext4_end_aio_dio_nolock() and
    ext4_ext_direct_IO().

[Lol Phirae]

cat Change | grep ext4

Ano, to samo o sobe staci.

[Bedňa]

OK, grep ext4 Change by stačilo, ale to by som ťa asi nepobavil.

[Michal Kubeček]

No a co?

[Martin Mareš]

Musím sa hanbiť, ale v robote mám Widle, tak som to pozeral len vizuálne a vyzeralo to ďaleko horšie Ale aj tak pripájam čo som nagrepoval ja, ext3 ani nedávam.

Jenže já právě o ext3 mluvil, takže mi, prosím, neoponujte hromadou záznamů o ext4, když je řeč o ext3

Ale podívejme se tedy na ext4. Ano, v něm se stále bugy opravují – to je pro takhle mladý a takhle rozsáhlý kus softwaru zcela normální (pokud se tedy nevyvíjí a netestuje tak důkladně jako software pro raketoplán, ale při tak precizním způsobu vývoje bychom se asi ext4 hned tak nedočkali). Co je důležité, je, že to jsou (alespoň podle zběžného průzkumu a diskusí v mailing-listech, tak detailně vnitřnosti ext4 neznám, abych to tvrdil s jistotou) bugy, které se projevují jen ve velmi specifických případech a nezpůsobují ztrátu dat.

To, že vidíte v changelogu spoustu oprav zrovna tohoto druhu, je spíš dobrá zpráva. Znamená to, že hlavní práce je hotova, ale i přesto se pořád autoři věnují kódu natolik intenzivně, aby takové maličkosti vychytali. Takové péči se těší málokterý program. I ext2/3 si touto fází před pár lety prošly a staly se z nich právě díky tomu opravdu stabilní filesystemy.

[Bedňa]

OK, ja som písal ext3 a ext4, to že si to otočil len na ext3 som si nevšimol, tak prepáč, fakt nemám chuť sa hádať, napísal som svoju skúsenosť a pokial máš doma nejaký starší komp, môžeš si to vyskúšať, tam ten rozdiel pocítiš zretelne, samozrejme pokial si spokojný s ext3/4 tak tento zápis ignoruj, ja som aj zápisok začal otázkou "Stáva sa Vám že ..." v závere "môžete vyskúšať", teraz by som to ale určite celé napísal výstižnejšie.

[Martin Mareš]

Tady ale mícháte dvě věci: Subjektivní tvrzení o rychlosti FS (se kterým nepolemizuji, byť mi doma ext3 funguje báječně i na 12 let starém HW) s mylným tvrzením o jejich zabugovanosti (proti čemuž jsem se ohrazoval).

Ale po pravdě řečeno, daleko hodnotnější by bylo, kdybyste místo snůšky subjektivních tvrzení něco doopravdy změřil – to by se tomu pak jistě rádi věnovali i vývojáři jádra a problém, který pozorujete, by pravděpodobně odstranili.

Ale když ono je holt jednodušší o věcech tlachat, než přiložit ruku k dílu...

[Bedňa]

Náš administrátor shledal tento komentář závadným.

Vulgární a zbytečné.

Zobrazit komentář

[Lol Phirae]

Velmi dekuji za fundovany, detailni a argumenty podlozeny rozbor problematiky ext3/ext4 v linuxovem jadre. Bylo to velmi poucne.

[Bedňa]

Nie som odborník na túto oblasť, takže fundované a detailné argumenty nečakaj, ale zato si viem naformátovať partíciu

[disorder]

ani na chvilu o tom nerozmyslam, pretoze:

* mi tu presadzujes nicim nepodlozeny nazor
* chces odo mna aby som riesil problem, ktory nepocitujem
* sposobom na ktory nemam kapacity a urcite ani cas

[Bedňa]

Správne, neopravuj čo funguje, to je skôr pre takých čo tento problém pociťujú.

[Matlák]

Tak nějak. Já používám ext3 už bezmála 6 let a nemám s ním jediný problém. Jediná nepříjemnost která mi kdy na něm vadila bylo pomalejší mazání opravdu velikých souborů. Jinak spolehlivost 100%, nikdy, opakuju nikdy se mi z žádné ext3 partišny neztratily data a to ani po problémech s napájením a jedním vadným diskem. Většinu svých ext3 partišen mám navíc "zabalenou" v Truecrypt oddílech. A co se rychlosti týče, asi jsem si zvykl - věřím že reiser4 nebo jiné (xfs?) filesystémy jsou rychlejší, ale když čtu o těch problémech při zaplňování nebo při náhlém výpadku napájení, nestojí mi to za to...

[Martin Mareš]

To, co mi na ext3 přijde opravdu úžasné, je fsck. Už jsem několikrát přišel k disku, kterému chyběla čtvrtina oddílu (ať už nečitelná nebo přepsaná), a fsck po hodině mumlání si pod fousy čísel průchodů, která jsem ještě nikdy předtím neviděl, dokázalo rekonstruovat většinu důležitých dat. Před tím smekám, to jsem zatím u žádného jiného FS nepotkal.

[Bedňa]

Keď používaš len ext, tak sa s tým aj asi aj ťažko stretneš, mne keď začala štrajkovať doska, najprv občasnými výpadkami, tak som sa asi až po dvoch mesiacoch odhodlal riešiť problém, začal som vyťahovať karty, meniť ramku, procák atď až som sa dostal na 10 samočinných resetov za hodinu, keď som všetko vylúčil, tak ostala už len doska, samozrejmi pri toľkých prerušní zápisu prišlo k chybe na disku, spustil som reiserfsck a vštky dáta mám v poraidku, nechcel by som to zažiť s ext3.

[Lol Phirae]

spustil som reiserfsck a vštky dáta mám v poraidku, nechcel by som to zažiť s ext3.

Ano, mel jsem kdysi na instalaci nekolik novych pocitacu, ktere po zdarne instalaci systemu po prvnim rebootu skoncily se zlikvidovanym, neopravitelnym souborovym systemem. Spolehlive, kazdy jeden z nich (totozny HW). No, hadej co na tom disku bylo za FS? Aaaano, spravne, vynalez pane Reisera. :P ext2, ext3, xfs - naprosto bez problemu. reiserfs neprezil nikdy ani prvni reboot. Takze asi tak. :P

[Bedňa]

Ja sa nechcem hádať čo je lepšie, kľudne používaj ext3/4, pokiaľ máš moderný komp a dosť ram. tak to asi ani nepostrehneš, hlavne nepoužívaj Widle Tam je každá rada márna Aj ma štve že v poslednom čase je komunita dosť rozhádana a keď hocikto napíše svoje skúsenosti nevyhne sa kritike a dokazovaniu, kedysi to bolo o diskusií, dnes viac o hádke, to čo píšeš o ReiserFS som nezažil ani raz a to ho dávam na každý komp, ako som písal po dlhej dobe som vyskúšal ext4 a zas tie spomalenia, samo že mám starý komp a vždy som o nejakú tú generáciu pozadu, lebo ako vývojár mám pocit že keď to pôjde mne, pôjde to každému Určite ale keď niekomu niečo spalahlivo funguje, tak je to škoda spravovať, akurát sa to tak môže pos...

[Heron]

Aj ma štve že v poslednom čase je komunita dosť rozhádana a keď hocikto napíše svoje skúsenosti nevyhne sa kritike a dokazovaniu, kedysi to bolo o diskusií, dnes viac o hádke,

Tak začni u sebe. Věty nechcel by som to zažiť s ext3, hlavne nepoužívaj Widle Tam je každá rada márna apod. ke kvalitě diskuse moc nepřidávají.

[Bedňa]

OK, berem.

[kralyk z abclinuxu]

spustil som reiserfsck a vštky dáta mám v poraidku, nechcel by som to zažiť s ext3

Ano to zní opravdu fundovaně.
Při násilném přerušení zápisu na disk, ať už jich bylo kolik chtělo, stačí pročíst žurnál a opravit poslední akce. Žádná velká nekonzistence se nekoná. Čili v takové situaci rozdíl mezi ext3,reiser,xfs,jfs,... prakticky nepoznáš. Rozdíl by byl poznat jen u filesystémů bez žurnálu.

Reiserfsck je nejhorší příšernost, srovnání s ostatníma fsck nástrojema naprosto nesnese. Program, který oznamuje neúspěch při recovery filesystému (ne chybu programu) tím, že vyhodí SIGABRT, který vrací návratové hodnoty v rozporu s dokumentací, a který potřebuje dost netriviální znalost svého (dokumentací ne moc dobře popsaného) chování v praxi, by na tak kritické rovině jako je konzistence filesystému neměl vůbec mít co dělat.

Abych byl spravedlivý: když člověk pochopí, jakým způsobem má reiserfsck ovládat, toleruje občasné SIGABRTy, zná správnou sekvenci reiserfsck příkazů a celkově "ví do čeho jde", dosáhne s reiserfsck pří obnovování dat docela dost dobré výsledky. Na příšernosti chování tohoto programu to ale bohužel nic nemění...

[Bedňa]

Zabudol som podotknúť, že na tej doske odchádzal práve radič disku, čo spôsobovalo dosť ťažké chyby na disku a systém už bol v dosť nekonzistentnom stave ale o to som sa nestaral a reebotoval som doomrzenia, kým som nezistil kde je chyba, takže v akom stave bol žurnál je už asi dosť ťažké povedať, ale reiserfsck to po výmene dosky spravil, ako som už v diskusií spomínal s dosť výkonným systémom a ram, sa spomalenia neprejavia a neviem prečo na toto všetko reagujem, keď som chcel vlastne len dať alternatívu ľudom, ktorí práve také problémy ako som popisoval pociťujú.

[kralyk z abclinuxu]

Reiser má zas jiné problémy. Si člověk nevybere. Volba FS je vždycky kompromis.

[Kvakor]

Reiser4 nepoužívám, ale Reiser3 mám už dlouhou dobu na druhém disku, kde jsou převážně data. Starší verze se šíleně dlouho (cca. 10 sekund) mountovaly, novější verze už to sice nedělají, ale pokud se potřebuje poprvě přistoupit k souborům, tak až několik sekund trvá, než se načtou do paměti nutná metadatat, během kterých z disku nelze číst ani na něj zapisovat. Obdobvné je to i při "vyhození" těchto metadat z cache.

Naštěstí je obejití tohoto problému celkem jednoduchým způsobem - stačí přistoupit k nějakým datům hned po namountování, nejlépe na pozadí, čím se napodobí starší chování, ale bez brzdění ostatních procesů.

[Semo]

Nikdy som si nic pododobne nevsimol. A to pouzivam reiserfs roky na 4 pocitacoch.

[Kvakor]

Pokud je namontovaný jako root, tak se to tolik neprojeví, stejně jako pro male velikosti (tj. menší než desítky GB) a disky, které jsou téměř nebo úplně prázdné a metadat je na nich minimum.

[vlastikroot]

Mě se to projevuje v home, mám tam všelijaké ledacosy a opravdu, trvá tak sekundu, než to ten FS vytáhne. Podruhý už je to ok.

[Bedňa]

Tak to pochybujem že je problém hocijakého FS, skúsil by som pozrieť S.M.A.R.T.

[pht]

Ono to není ext nebo reiser. Existuje ještě spousta jiných fs.

[frr]

Tohle jsem už taky zjistil. Resp. já to pozoroval před pár lety na EXT3, nejdřív na nějakých externích polích (200-800MBps), pak i na samostatném Cheetahu. Jednalo se o dlouhodobý "problém". Stačí spustit Bonnie++2, nejlíp v několika instancích (pro každé CPU jádro jednu), případně každou instanci zasmyčkujte, aby běžela pořád. Výsledek by se měl dostavit během pár minut: systém se tváří jako že všecko OK, spotřeba CPU spadne na nulu, jednotlivá vlákna Bonnie++2 jsou zablokovaná v nějakém syscallu. Podle mého se zasekne i bash, pokud ho máte na některé konzoli otevřený - systém přestane být schopen číst z disku. Podle mého to způsobuje test vytváření a rušení adresářů. Reiser 3 tím procházel bez problému.