Jaderné noviny – 9. 6. 2010 (diskuse)

[Bedňa]

Jak pekne začínajú tie riadky o ZFS, už som sa tešil že budem mať čím nahradiť Reisera, ale zas nič.

[xm]

Btrfs je pro Linux podstatně lepší řešení než ZFS.

[VSi]

Proč? (bez ironie)

Má (bude mít) Btrfs vlastnosti ekvivalentní výhodám ZFS? Jako RAID-Z, kontrolní součty dat i metadat (tohle asi ano), co možná největší zajištění konzistence při výpadku napájení a ztrátě obsahu cache, klasické user a group kvóty (ne jenom kvóta na adresář / filesystem). V low-level architektuře se tolik nevyznám, ale z prezentace o ZFS jsem měl pocit, že je to fakt hodně chytře udělané. Možná jen dobrý marketing SUNu.

Jinak bude asi trvat velmi dlouho, než Btrfs dosáhne kvality a spolehlivosti ZFS. ZFS je už nějaký čas v produkčním nasazení, jsou na něm reálná data. Četl jsem i velmi zajímavý článek o automatizovaných testech ZFS - mají stovky strojů, na kterých se ZFS automaticky testuje vč. tvrdých výpadků napájení, poškození dat na discích apod.

[Laco]

Ty brdo vy ste iny magori, riesite somariny ako file system. Kupte si Windows 7 a zacnite zit normalny zivot...

[F.]

Az bude vediet napr. win2008 server nabootovat zo zariadenia, ktore bude obsahovat particiu vacsiu ako 2TB, tak sa nad MS riesenim bude tak mozno aj uvazovat...

[Laco]

Ano bezpochyby je to hanba, posrate 2TB, dnes uz to ma kazdy mobil... LOL :)

[Jakub Lucký]

Vy instalujete Windows server na mobil? Já instaluju serverový OS na server. A server může mít pole. Třeba z 32 disků... a to je pak hodně TB

[Jardík]

Windows Server 2008, tak Windows Vista a Windows 7 z takového oddílu nabootovat "umí". Resp. nabootuje ho EFI. A pokud tvůj komp EFI nemá, tak si říkáš o problémi i v Linuxu. Sice to grub tak tak rozchodí a je schopný z toho různými "hacky" nabootovat, ale takový gparted ještě nedávno na GPT disku rád promazával zavaděč v MBR.

[F.]

Osobne som to neriesil, kedze nemam v sprave windows servery, ale kolegovia s tym bojovali a vysledok bol (lovim v pamati), ze po konzulacii s Dellom/MS a prehrabani sa googlom bol vysledok vytvorit na poli jeden "logicky" disk na system (/dev/sda) mensi ako 2TB. Druhy "logicky" disk (/dev/sdb) sa potom riesil vo windowse z cmd, kde sa urobil prevod na gpt a potom to uz nemalo problem s 2TB limitom. Problem bol, ze win2008 proste nevedel z instalatora vytvorit viac ako 2TB (a ak sa to napr. nastavilo inak napr. z linuxu) a chcelo sa instalovat, tak win nebol ochotny z takejto particie bootnut (ak malo to zariadene, z ktoreho sa malo bootovat GPT). Povodny zamer bol totiz /dev/sda1 (system) a /dev/sda2 (data).

[xm]

Doporučuji k přečtení článek Krátká historie Btrfs (překlad článku od věhlasné Valerie Aurory). Sice je už trochu staršího data, ale dost toho vysvětluje.

[Milan Jurik]

Ty jo, Valerie uz je dokonce vehlasna Jen nevim, jak odpovida na otazky tazatele

[xm]

Ano, věhlasná mezi vývojáři souborových systémů opravdu je. Ten článek mimo jiné ukazuje, proč má Btrfs lepší návrh než ZFS a proč je vhodnější pro Linux. Co se týče vlastností Btrfs, tak ty jsou přehledně popsány např. na btrfs.wiki.kernel.org.

[Milan Jurik]

Kazdy chapeme vyznam slova "vehlasna" asi jinak. Ja jen muzu soudit na zaklade toho, cim skutecne prispela

btrfs ma nepochybne novejsi design (ktery umoznuje jistou podmnozinu operaci implementovat jednodusseji), ale ani ten dalsi odkaz neodpovida na otazky tazatele asi dostatecne.

xm, tve navazeni se do ZFS je letite, tva bezmezna ucta k btrfs uz je take dlouhodoba (snad od chvile, kdy se objevil prvni kod). Ale obcas by to chtelo nehazet jen odkazy asi. Cimz btrfs nechci nijak shazovat.

[Radovan Garabík]

Tato omezená verze bude pravděpodobně začleněna s tím, že doba spotřeby vyprší v 2.6.27

- asi to má byť 2.6.37...

[chrono]

Podľa originálneho článku to má byť naozaj 2.6.37

[pozortucnak]

Jsou pro linux i jiné použitelné souborové systémy s transparentní kompresí? ReiserFS odešel do věčných lovišť, Btrfs je nestabilní, jediné, co se mi zdá (zatím) použitelné je zfs-fuse.

[xm]

Osobně považuji Btrfs už za vcelku stabilní (i když samozřejmě s nějakým kritickým serverových nasazením by asi bylo záhodno pro sichr ještě počkat). Rozhodně lepší než ZFS přes Fuse.

MeeGo ho již nasazuje jako defaultní filesystem. V nejnovějších verzích Ubuntu, Fedory a OpenSUSE už je také podporován (včetně takových vychytávek jako snapshot a případný rollback systému při aktualizacích).

[Nikola Ciprich]

"i když samozřejmě s nějakým kritickým serverových nasazením by asi bylo záhodno pro sichr ještě počkat"

u takto komplexniho fs ktery jeste nema ani stabilni diskovy format? tim jeste pockat myslis aspon 3-5 let ne?

[trekker.dk]

u takto komplexniho fs ktery jeste nema ani stabilni diskovy format?

Podle varování v Kconfigu ne, fakticky jo, diskový formát už se nezměnil hodně dlouho.

[Milan Jurik]

Nesla nahodou pred par dny zprava, ze tvurci zavadeji verzovani formatu, takze by dalsi zmeny formatu mohly byt uz pred uzivateli skryty, tak jako je to ZFS?

[Nikola Ciprich]

to ze se nezmenil uz dlouho jeste nic neznamena, i v dnesnim gitu je stale oznacen jako unstable a cely fs jako experimental, na to bych si dal tak maximalne /tmp, o nejakem nasazeni na servery nemluve...

[poky74]

"ReiserFS odešel do věčných lovišť"

To mi vysvětlete, něco mi uniklo?

[pozortucnak]

Vývoj ReiserFS 4 je přinejmenším nejistý... Potřebuji spolehlivý souborový systém s podporou transparentní komprese. Který byste my doporučil?

Btrfs je nový, když jsem ho nedávno zkoušel, tak měl problémy a komprese nefungovala.

ReiserFS 4 nejistý vývoj...

zfs-fuse - podpora komprese, mělo by to být bezpečné, netřeba kontrolovat integritu dat...

fusecompress - nevěřím mu, co se stane s daty při tvrdém restartu?

Mě z toho vychází nejlépe zfs-fuse, krom toho se vyvíjí jaderný modul...

[poky74]

Však je to dobrej systém, to není nikdo kdo by reisera vyvýjel? Kdy pustěj toho vrahouna?

[JVid]

Edward Šiškin (vývojář Reiser4) plánuje svoje dílo v brzké době začlenit do vanilky, takže by ta nejistota kolem vývoje mohla trochu opadnout, a „starý“ ReiserFS je sice málo udržovaný, ale to je spíš příznakem toho, že je dost stabilní a prostě není potřeba ho dál upravovat. Mimoto do něj nedávno přistálo obrovské množství patchů kvůli akci „Kill the Big kernel lock“, tudíž nějaká údržba probíhá a jeho jaderný kód ještě zcela neosiřel.

Jediný problém ReiserFS je to, že se při návrhu nepočítalo s ACL, kvótami nebo xattry, takže tyhle modernější fce do něj byly dost ošklivě dohackovány a jejich používání není tolik otestováno (osobně mám právě s rozšířenými atributy špatné zkušenosti). Dnes se od jeho používání odrazuje, já ale vážně nevím proč. Pořád je to FS dost rychlý a v porovnání s Ext4 nebo brtfs je IMO i stabilnější.

[trekker.dk]

Edward Šiškin (vývojář Reiser4) plánuje svoje dílo v brzké době začlenit do vanilky, takže by ta nejistota kolem vývoje mohla trochu opadnout

Plánuje neznamená, že mu to projde.

ReiserFS je sice málo udržovaný, ale to je spíš příznakem toho, že je dost stabilní a prostě není potřeba ho dál upravovat.

A přesto je schopný samovolně se rozsypat na funkčním hardwaru.

[JVid]

Plánuje neznamená, že mu to projde.

Doufat ale můžeme, ne?

A přesto je schopný samovolně se rozsypat na funkčním hardwaru.

Myslíš tu známou chybu s xattrs? Hans byl sice hovado, ale věděl, proč nackovat přidávání vlastností, na které ten FS nebyl stavěný. Když ho ostatní vývojáři přehlasovali, mají, co chtěli.

[trekker.dk]

Myslíš tu známou chybu s xattrs?

Myslím, že ne, protože xattrs se tam nepoužívaly.

[Bedňa]

Nenavážaj sa do môjho oblúbeného FS, čo je potom šmejďárna ext2,3,4? S extom som si zažil svoje, je to hnus velebnosti.

[Martin Mareš]

Pokud mi předvedete jakoukoliv chybu v ext2/3, která by mohla vést ke ztrátě dat, máte u mně pozvání na čaj nebo na pivo podle vlastního výběru

[Mrkva]

Hm, třeba tady? Novější jsem nenašel :)

[Martin Mareš]

Za bug, který existoval naposledy před 8 lety, u mně máte pozvání taktéž před 8 lety

Já myslel něco alespoň trochu současného.

[JVid]

A ReiserFS má nějaký současný (otevřený) bug?

[Martin Mareš]

To netvrdím. Zato pan kolega o pár příspěvků výše tvrdil, že ext2/3 nestojí za nic, tak jsem ho vyzval.

ReiserFS sám nepoužívám, jen k němu mám velmi subjektivní nedůvěru danou tím, že jsem jeho zdroják četl a nevěřím tomu, že by něco napsaného takhle mohlo být správně Naproti tomu ext3 má kód mile přímočarý.

[Bedňa]

Napríklad ja pred mesiacom, dáta s celého disku. Zas som dal šancu extu, teraz vo verzii 4.

[Martin Mareš]

No to mi je líto, že jste přišel o data, ale jak jste poznal, že je to chyba filesystemu?

[Bedňa]

Teraz už bez predošlých emócií. No chcel som pretaktovať procesor na vyššiu frekveciu. Pretože sa procesor bránil, tak úspešnému štartu predchádzalo približne desať reštartov, potom upozornenie na to že systém nieje konzistentný. OK spustím fsck vyhodí niekoľko chýb a opraví ich, ale s pripomienkou že nieje všetko úplne OK, aby som fsck spustil s nejakým parametrom. Pre istotu som najskôr nabootoval všetko OK. Tak si hovorím čo sa môže stať pri nejakej banalitke na disku. Tak som spustil fsck s tým parametrom (neviem už akým) data komplet v prdeli, nepomôhlo už nič, ani rady zaritých exťákov. Neviem možno mám smolu, ale keď mi odišiel radič na disku s Reiserom a potreboval som dokončiť súrnu prácu, tak mi reštartoval komp desať krát denne a až po niekoľkom dni Reiser zahlásil že chce opravu a všetko prebehlo OK. Teraz ho mám v druhom kompe a stále na tom "mrtvom" Reiseri idem. Nehovoriac o ďaľších vlastnostiach, ale o tom som už písal inokedy. S extom som začínal ako každý Linuxák, ale kto si vidí pred nos a rád porovnáva a skúša, tak ho rýchlo zavrhne, nemyslím len na chybu čo som opísal, ale chod systému, nevysvetlitelné spomalenia, problémy so softom, ktoré si nezapisujem a preto to ani nijak dokazovať nechcem, ale každému kto narazí na nevysvetlitelní problém doporučujem skonči s extom a veľa ľuďom to pomôhlo, nielen Reiser.

[Mrkva]

Hm, takže lamerský zásah do HW :) Ten FS mohl odpálit chybující procesor, nebo RAM (pokud jsi taktoval změnou frekvence FSB).

[Bedňa]

Lenže ten lámer používa Reiser celé roky a ešte o nič neprišiel.

[Martin Mareš]

No já si především myslím, že pokud někdo přetaktovaný procesor pustí na živá data, místo aby ho delší dobu testoval na read-only filesystemu nebo nějakém Live CD, tak má neskutečné štěstí, že o ta data přišel jenom jednou.

[Martin Mareš]

No chcel som pretaktovať procesor na vyššiu frekveciu. Pretože sa procesor bránil, tak úspešnému štartu predchádzalo približne desať reštartov, potom upozornenie na to že systém nieje konzistentný.

Když ono se při přetaktování procesoru může stát ledacos – a poměrně běžně se například stává, že procesor uvnitř funguje OK, ale nestíhá komunikovat s okolím, takže třeba může místo všech dat na disk zapisovat nuly (případně zapisovat o kousek vedle). To z počátku vypadá nevinně, ale pak zjistíte, že je přepsaná komplet celá struktura filesystemu. (Už to, že si ext3 stěžoval, že je FS nekonsistentní, místo aby prostě chybu opravil podle žurnálu, naznačuje, že to maličkost nebyla.)

Pokud se vážně stalo něco podobného, pak nemůžete mít žádnému FS za zlé, že to nepřežil.

(Kdysi v dávných dobách jsem opravoval disk, který se někdo pokoušel 5 minut používat ve stavu, kdy řadič zapisoval 7. bit každého 16-bitového slova jako nulu. Takový puzzle se ještě za pár hodin ruční práce s hexeditorem složit dá.)

S extom som začínal ako každý Linuxák, ale kto si vidí pred nos a rád porovnáva a skúša, tak ho rýchlo zavrhne, nemyslím len na chybu čo som opísal, ale chod systému, nevysvetlitelné spomalenia, problémy so softom, ktoré si nezapisujem a preto to ani nijak dokazovať nechcem, ale každému kto narazí na nevysvetlitelní problém doporučujem skonči s extom a veľa ľuďom to pomôhlo, nielen Reiser.

Vida, a já radím přesný opak: pokud se vám systém chová nespolehlivě a záhadně, zahoďte všechny ostatní filesystemy a použijte starý dobrý ext2/3. Vrchol moderního návrhu to rozhodně není, výkon má slušný, ale ne špičkový, ovšem co do spolehlivosti ho v linuxovém světě vážně nepřekoná vůbec nic. A také vím, co je uvnitř

[Bedňa]

Kamaráde je neviem čo je vo vnútri to sú len moje skúsenosti za čo ma zatracujú. Ja si pre mňa nepodstatné veci nezapisujem, hoci som aktívnym hlásiteľom chýb v projektoch ktoré ma zaujímajú. Som zaregistrovaný asi vo všetkých bugzilách čo existujú :) Reiser ide celé roky sám, možno mám len šťastie, ale po tom čase aj keby sa už konečne niečo stalo, asi by som to skôr pričítal HW. Väčšina ľudí si myslí že Linux je nejak závislí na extoch, čo našťastie nieje pravda.

[Heron]

Reiser ide celé roky sám, možno mám len šťastie, ale po tom čase aj keby sa už konečne niečo stalo, asi by som to skôr pričítal HW.

HW problém byl ale i v tom případě přetaktovaného padajícího stroje s ext3.

[Martin Mareš]

Já se hlavně už mnoho let chechtám tomu, že nejvíc řečí o tom, jak je který filesystem skvělý a jiný stojí za bačkoru, mají lidé, kteří žádný nikdy neviděli zblízka.

[poky74]

To jako při pohledu na plotnu? Vyjadřujte se konkrétně.

[Bedňa]

Tak to si ten komp budem asi musieť dať bližšie k sebe.

[Michal Vyskočil]

Martin spíše myslel podívat se na zblízka na git.kernel.org.

[Bedňa]

Myslíš kritiku štýlu kódu? Ale to je vec ostatných kvázi programátorov takých ako som ja, že myslíme len jednoducho. To nič nemení na tom že reči odporcov sú len čisté drísty, hoci ma mrzí že to vyslovili aj ľudia od jadra. Ale predsa sa nemôžeme stotožňovať s vrahom že? Radšej budeme plácať ext2,3,4,5,9999 a stále vytvárať nové bugy, ale náš systém bude ideologicky čistý, s prehľadným kódom, hoci bude stáť za ...

[Martin Mareš]

To nič nemení na tom že reči odporcov sú len čisté drísty

A Vaše řeči nejsou? Nevšiml jsem si, že byste vyslovil jediný solidní argument proti ext3.

[Martin Mareš]

Ale to je vec ostatných kvázi programátorov takých ako som ja, že myslíme len jednoducho.

Na to samozřejmě máte plné právo. Jen se pak nesmíte divit, že to, co tvrdíte, sotvakdo bere vážně

[Bedňa]

To je pravda, ja to tiež beriem skôr ako povzdych nad tým, ako jadráci odstavili pre mňa najlepší natívny Linuxový FS.

[Jardík]

Jak moc myslíte, že by bylo reálné dostat do kernelu do ovladače cdrom nové ioctl CDROM_GET_EXCLUSIVE_ACCESS (nebo tak něco) s následujícím chováním:

• CDROM je otevřen více než jednou, volání by selhalo
• CDROM je otevřen pouze jednou, dostanu exkluzivní přístup. Každá další aplikace volající open() na dané zařízení by dostala chybu (např. EBUSY), nehledě na mód přístupu.
• Po zavření deskriptoru by byl příznak odstraněn (tj. kdyby root chtěl přístup, stačí zabít proces přistupující k zařízení a přístup dostane).

[Mrkva]

Napiš patch, pošli na mailing list a uvidíš, ne?

To to nejde nějak rozumě udělat v userspace, že to chceš prasit do kernelu?

[Jardík]

A jak to uděláš v userspace? Pokud otevřu s O_EXCL cdromku přes /dev/sgX, tak mi jí to dá exkluzivně a nic ji neotevře ani pouze pro read. To platí ale jenom o /dev/sgX. Pokud to samé udělám pro /dev/sr0, tak ji jen neotevře program, co to opět zavolá s O_EXCL, ale program, co zavolá open bez O_EXCL ji stejně otevře a může posílat SCSI příkazy, co podělaj proces vypalování. Navíc O_EXCL pro srX a sgX se vzájemně nevylučují a lze tak opět podělávat vypalování. A jelikož lze SG_IO posílat jak přes srX tak sgX, tak je to určitě nějak vzájemně "propojené" a mohlo by to fungovat pro obě rozhraní najednou. Nebo to třeba nazvat jinak (třeba s SG_ prefixem). Zkusím kouknout do zdrojáků jádra.

[Jardík]

Tak trošku pomáhá fcntl/F_SETLK, ale to zase pomůže jen proti otevření bez O_NONBLOCK. Pokud je tam O_NONBLOCK, tak se to stejně otevře. Takže je situace:

• Otevřu /dev/sgX s O_EXCL a O_NONBLOCK
  • Žádná jiná aplikace už /dev/sgX neotevře
  • Aplikace však může otevřít /dev/srX a podělat tak vypalování
• Otevřu /dev/srX s O_EXCL a O_NONBLOCK, použiju fcntl/F_SETLK(RW) na zamknutí
  • Žádná aplikace to neotevře s O_EXCL flagem
  • Žádná aplikace to neotevře bez O_NONBLOCK flagu (např. mount nebude fungovat)
  • Aplikace, která nepoužije O_EXCL a použije O_NONBLOCK to klidně může otevřít (a v případě DVD-RAM třeba i RW a pak pálí samo linuxové jádro) - to má za následek podělání vypalování
  • Každá aplikace přistupující přes /dev/sgX může podělat vypalování
• Otevřu jak /dev/srX tak /dev/sgX způsoby popsanými výše.
  • Každá aplikace přistupující přes /dev/sgX má smůlu, každá aplikace otevírající /dev/srX s O_EXCL má smůlu, každá aplikace otevírající bez O_NONBLOCK má smůlu.
  • Aplikace, která přistupuje přes /dev/srX, nepoužije O_EXCL a použije O_NONBLOCK může podělávat vypalování
• Se staršími jádry lze přistupovat přes /dev/hdX - další trable nastávají.

Koukal jsem na ty zdrojáky, koukal jsem na ovladač cdrom, na scsi (sr, sg) "věcičky", na ide věcičky, vypadá to, že každé si dělá "na svém písečku", je tam spousta duplikátních věcí ... fakt netuším, kam bych měl nové ioctl dát, aby to mělo efekt na všechna rozhraní pro cdromy