Názory k článku
Linux 4.0.2 trpí selháním souborového systému ext4
-
To je samozřejmě dobře, ale stále to neznamená, že Arch má stable vydání, o kterých je tu řeč. Zatímco v Archu a Gentoo se stále mění verze, Debian, Ubuntu a třeba Fedora vydávají stable vydání. To znamená, že do Debianu 8 Jessie, který tu teď mám, se jádro 4.0 nikdy nedostane, protože je tam jednou pro vždy 3.16. O tom mluví zprávička.
-
pet (neregistrovaný)
To je slovíčkaření. Lze to taky pojmout tak, že rolling release distribuce má stabilní vydání z balíčků považovaných v daném okamžiku za stabilní. Např u Gentoo (updatoval jsem 15.5.) mám stabilní 3.18.12, ale dostupné je již i 4.0.3, to ovšem zatím za stabilní považováno není a asi ani nikdy nebude.
-
Nikoliv, v tom je naprosto zásadní rozdíl: u stable vydání je garantována podpora těch konkrétních verzí balíčků – v případě Debianu to je pět let. Znamená to tedy, že teď budu mít na tomhle počítači pět let Jessie a nikdy se mi tam nedostane nová verze balíčku, která by něco rozbila. V rolling release tohle nefunguje, tam je za týden verze 5 přepsána verzí 6 a jede se dál.
-
Naopak, přesně takhle to v Debianu (a jinde) funguje. V Jessie je jádro 3.16 a nikdy tam ani jiné nebude. Přesně tohle je smyslem stable vydání = verze jsou stabilizované – jednou provždy zmražené. Nedojde k aktualizaci na 4.0.2, která sejme souborový systém nebo se nenainstaluje nová verze web serveru, který by potřeboval předělat konfiguraci.
-
Michal (neregistrovaný)
Nic není tak růžové jak se zdá. Idea je to dobrá, ale vše dělají jen lidi a ty dělají čas od času chyby. Naposledy jsem řešil asi 2 hodiny proč mi nefunguje moje aplikace až jsem zkusil downgrade php, které mělo opravovat pouze bezpečnostní chyby (na wheezym) a teprve se to rozběhlo. Potom jsem našel, že kolega z prvního postu něco špatně napatchoval a tím to rozbil. Takže i do stable se dostávají chyby, které můžou rozbít provoz.
-
Taky jsem si vzpomněl na sebe a PHP, když Petr napsal to absolutní prohlášení o tom, že Debian je rock stable.
MySQL se opravuje tak, že se pushne nový upstream (hlavně kvůli přístupu Oracle k vydávání bezpečnostních patchů). U PHP jsme se domluvili taky tak, protože mít starší PHP s miliónem patchů vylovených bez kontextu bylo snad ještě větší zlo...
-
Jsi si tim jista? Krome toho u horke novinky jednou ta chyba muze byt v Btrfs. Navic si nemuzes byt jista ani tim, ze v Btrfs ta chyba neni. Muzes rici jen to, ze zatim na ni nikdo nenarazil, coz se zitra muze zmenit. O chybe se zatim nevi, co ji zpusobuje. To muze znamenat i to, ze finalni zprava bude, ze problem muze vzniknout i u jinych FS.
-
bubla (neregistrovaný)
Já mám s BTRFS taky hrozné zkušenosti, na Ubuntu tak dva roky zpátky a pak na Archu půl roku zpátky.
Celkem mi BTRFS za 4 roky, co jsem ho nasazoval, během posledních dvou let rozhasil 4 oddíly (a to jsem se ani nerýpal v jeho konfiguraci). Pamatuji na doby, kdy byl ReiserFS "unstable" a s tím jsem měl za ty roky přesně 0 problémů (ještě dnes mi někde běží). -
BTRFS uz nikdy nikam nenainstaluju. Takovy problemy jako BTRFS sem jeste nikdy nemel. Staci aby vypad proud nebo se necekane restartoval pocitac a clovek musi rucne mazat log, aby moh vubec disk namountovat, coz je samozrejme dost neprijemny kdyz ma clovek na BTRFS root.
Pravda uz se to delsi dobu nestalo, ale proste uz tomuhle bastlu neverim... -
tom (neregistrovaný)
Promiňte, ale u takového výkřiku by ste měl uvést datum. Také je dost pravděpodobné, že v době, kdy se vám to stávalo, nikdo neprohlašoval btrs za stabilní. Používám btrfs již několik let a ano při výpadku to kdysi mohlo dělat problémy, to je ale stará a dnes již neplatná zpráva. Stejně tak poznámka o bastlu je nevhodná v případě, že testuju novou věc, kterou nikdo jako stable "neprodává" (v té době).
-
No vzhledem k tomu, ze na to exituje i stranka na Wiki a byl sem schopnej podle hlasky vygooglit tohle reseni, tak to zrejme uz par lidi reportovalo, jen se to zrejme nepovedlo dobre opravit...
https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log -
tom (neregistrovaný)
O té stránce já vím a také jsem psal, že se to stávalo. Ale minimálně za poslední rok už u mě určitě ne. V samotné wiki je: "The common case where this happened has been fixed a long time ago, so it is unlikely that you will see this particular problem.". Takže by opravdu bylo vhodné to reportovat.
-
Trident (neregistrovaný)
Pamatuji leta pane kdyz vyhnivaly takove hvezdy jako veritas nebo jeste dymajici ZFS.
Zvlast u tech ZFS to byla jobovka. Vsechno pryc a nahrnout z pasek. Nikdo to neumel poradne opravit ani pomozi zdbg a byla to sazka na jistotu.Proste vrstvy nad FS jsou jenom kus softu ktery muze selhat.
-
-
Ondra Satai NekolaZlatý podporovatel(pokrci rameny) To at se pak lidi nedivej. Kdyz je nedostane chyba ve FS, sejme je odesly HW nebo si to smazou sami...
-
Dle komentářů
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672
to vypadá, že problémy jsou také při použití dm_crypt, NCQ a některých SSD.
Sám mám dm_crypt a SSD a pochopitelně nastaven "discard", ale asi jsem měl štěstí.
Nabootoval jsem s fsck.mode=force a chybu to nenašlo.
Dneska raději jedu na 3.16 -
Metrák (neregistrovaný)
Kdepak, jakmile to nemá LTS za jménem, určo nebrat! Dobří lidé ve firmě Canonical vědí, jaké jádro použít a kdy ho poslat do světa – v okamžiku kdy je odladěné, stabilní a v pořádku. Tyto exkrementy jsou pro bastlíře a testery, rozhodně ne pro nerváky a slušné, produktivní uživatele.
-
trubicoid2 (neregistrovaný)
tak od 4.0.0 vidim bug in na btrfs, bisecting vede na "Merge tag 'dm-3.20-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm"
coz obsahuje ty nove moderni opicinky s blk-mq; bohuzel proste vypnuti scsi_mod.use_blk_mq=0 nepomuze
jestli je to opravdu tak, tak to muze postihovat vicero fs, jak se tu jiz nekdo ptal
ja to vidim pri defragu, je to btrfs raid5 na 4 dm-crypt discich, data to neposkodi, vyhodi kernel bug
nahlasene to je, hlasit se to musi :)
-
Trubicoid2 (neregistrovaný)
Thin provisioning nemám a s mačkáním na monitor pozor! Tipuju, že nejsem ve vaší váhové ani výškové kategorii.
Jinak ten kernel bug se projeví při zatížení fs po 4-24 hodinách, jedno čím. Scrubem ne, ten nezapisuje. Tak proč zrovna ne defrag? Borci z btrfs maj nějakej skript, co dělá psí kusy se snapshotama, ten by šel taky použít.
