Vlákno názorů k článku
Red Hat končí s Btrfs, zřejmě nadobro
od martin1397 - HArdcore linuxaci nemaju radi ZFS kvoli nie idealnemu...
-
Izak (neregistrovaný)
Jasne NetApp ;-))) ... ZFS v jadre je i jako moduly, problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data a stacilo by to opravit, ale NEJDE ... a ro jak na freeBSD tak na solarisu ... kdyz jsem Oracle psal v diskuzi, ze nemit fsck.zfs je hloupost a kazdy FS se muze pokazit, tak to smazali
Dale ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool, tedy pro me na nic, ja kupuji disky a prodavam je do sw_raidu 5 ... rekli, ze zadne profi reseni tuhle vlastnost nema, tak jsem jim rekl ze ji ma NetApp a ten umi rozsirit RaidGrupu o disk a pak si clovek muze pustit restripe dat, aby byly vytizeny vsechny disky rovnomerne, to mi taky smazali ... nebot jak vsichni vime, neni lepsi reseni nez NetApp, hledali jsme 2 roky a nic nefungovalo tak dobre.
PS: Netapp je NAS,RAID pole, bezi nad FreeBSD, coz je tajeno, ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano) a umi mnoho protokolu a nad tim vsim umi delat lokalni snapshoty a prenaset je ne jiny netapp ... bezi na tom mnoho SAP reseni, nebo SQL (DB2/Oracle) a misto FC voli NFS, je to flexibilnejsi a rychlost je stejna, jen je treba zmenit NFS blok, na mnoho nahodnych operaci je lepsi jej mit mensi, dramaticky pak roste rychlost pro mnoho pristupu a klesa latence
-
@Izak
"problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data"
Tohle prakticky nikdy neni vina ZFS ale toho ze si uzivatel blbe navrhnul zpool storage.
Napr pokud si vyrobis zpool kterej se sklada ze dvou vdev, a do jedny vdev das 50disku a do druhy pouze 1 kus, staci aby ti ten single-disk-vdev kleknul a spolehlive prijdes komplet o celej pool.Ten priklad je ponekud Xtremni ale popisuje platnej princip, totiz "if any vdev in a zpool fails then all data in the zpool is unavailable.
Proto je nutny si predtim neco nastudovat a podle svych pozadavku na redundanci/speed/storage size si to cely navrhnout.Je to stejny jako posadit joudu kterej celej zivot drandil na kolobezce do F1 a pak si stezovat ze "ty Formule 1 jsou uplne na hovno"..................... protoze se ten jouda v prvni zatacce vysypal do prikopu.
"problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data a stacilo by to opravit"
O jakych nastrojich je rec??
Protoze cely ZFS je samo o sobe 1 velkej nastroj na opravu dat!Teda abysme si rozumeli-ja mluvim o OpenZFS coz je fork ZFS verze od Sun na kterym dela BSD komunita a kterej vzniknul predtim nez ZFS zhaftnul Oracle a zamknul ho.
"Dale ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool.."
Nevim jak je to u Oracle ale OpenZFS tohle samozrejme umi, zpool se rozsiri pridanim dalsiho vdev.
=> you can add more vdevs to the zpool after it is created.
Viz tutorial o ZFS:
https://drive.google.com/file/d/0BzHapVfrocfwblFvMVdvQ2ZqTGM/view
https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/Pokud te ZFS zajima vic, tady je posledni video kde vyvojar ZFS Allan Jude
( spoluautor
https://www.kobo.com/us/en/ebook/freebsd-mastery-advanced-zfs
a https://www.kobo.com/us/en/ebook/freebsd-mastery-storage-essentials )
vyvraci nektery FUD + informuje co se chysta novyho:
http://www.jupiterbroadcasting.com/116766/for-the-love-of-zfs-bsd-now-203/
Enjoy! -
Sten (neregistrovaný)
ZFS má problémy třeba u disků, které špatně implementují flush cache (potvrdí jej před zápisem). Výpadek proudu pak dokáže ZFS odrovnat. Přitom by to šlo vyřešit snadno, stačilo by odrolovat několik posledních transakcí do konzistentního stavu, ZFS všechna potřebná data má. Což by byla práce právě pro nějakou fsck-like utilitu spuštěnou po startu.
Předpokládám, že ten problém je, že nemůžete přidat další disk do vdevu, ne že nemůžete do poolu přidat další vdev. Třeba nejde mít 6diskový RAID-6 vdev a přidáním dvou disků z něj udělat 8diskový RAID-6 vdev. Btrfs i mdadm tohle umí.
-
anonym (neregistrovaný)
ZFS tohle samozrejme umi, kdyz ho slusne pozadas (zpool import -F|-m|-n).
Jestli tvuj pozadavek je FS ktery 100% funguje i kdyz hardware vyslovene lze (ignoruje cache flush, ignoruje zapisy, cte data z nahodnych mist, pise data na nahodna mista atd) tak chci videt co pouzivas. Moderni FS se snazi takovou situaci detekovat, aby si vedel kdy sahnout do zaloh.
Problem pridavani disku do existujiciho vdev je non-issue v ZFS target audience (enterprise). Problem je bohuzel hluboko ve vlastnostech on-disk formatu (a pozadavcich na stabilitu zapsanych dat/COW).
Nevim jak tohle btrfs dela, ale tipnul bych ze tam bude nejaky hacek (jako kdyz defragmentace rusi block-sharing snapshotu).kdyz uz o tom mluvis, zkousel si na btrfs RAID5/6 rebuild/resilver? IIUC je to porad cele rozsypane a nahodne ztraci data.
-
Sten (neregistrovaný)
Můj požadavek je nástroj, který to umí opravit. Ono se tohle může stát i na jinak spolehlivém HW, třeba protože umře baterka HW RAIDu. Nebo kvůli bugu v ZFS, třeba tenhle to dělal. zpool import -F jsem neznal, díky, bohužel vypadá, že na Linuxu není spolehlivý.
Btrfs to dělá tak, že provede rebalance. Žádný háček v tom není, Btrfs umí mít na jednou svazku různé RAID úrovně najednou (typicky se používá pomalý úsporný RAID pro data a mnohem rychlejší pro metadata), pak má během rebalance dvě sady (jednu původní RAID na 6 discích, druhou nový RAID na 8 discích) a data kopíruje z jedné do druhé. Block sharing se při tom zachová. Btrfs teoreticky umí i různé RAIDy pro různé subvolumy, ale chybí tam ioctl, aby to šlo nastavovat, a je otázka, jak se to vlastně má chovat, pokud by se mezi těmi subvolumy sdílely data, momentálně to spíš náhodně vybere jednu strategii.
Resilver byl opraven v listopadu. Ale pořád je tam write hole.
-
Adam KaliszStříbrný podporovatelNa Linuxu zrovna vyšla verze 0.7, třeba to opravila? Jinak na EuroBSDCon v Paříži bude tutoriál o OpenZFS od Michaela W. Lucase. Jsem přihlášen :-)
-
@adam kalisz
"na EuroBSDCon v Paříži bude tutoriál o OpenZFS od Michaela W. Lucase"Tak doufam ze budes referovat!
Urcite by bylo zajimavy slyset jak pokrocili s tou dedup tabulkou s promenitelnou/nastavitelnou velikosti tak aby to neposilalo system do kolen pokazdy kdyz nahodou vyzere komplet celou RAM.Taky to zpracovavani a DRZENI KOMPRIMOVANYCH DAT v RAM a odesilani snapshotu sifrovanyho datasetu do cloudu aniz by prijemce musel znat klic muze bejt hodne zajimavy.....
-
Ivan (neregistrovaný)
Nez se prislo na to, ze se takhle chovaji nektere disky od WD, tak se verilo ze problem je v XFS. Behem rebootu disk potrvrdil zapis dat, i kdyz je mel pouze ve svoji cache. Po rebootu byl FS poskozeny. ext3 to ale dokazalo ustat, zatimco XFS ne. A proto se dlouho hledala chyba v tomhle FS.
Jedna vec je jak je FS navrzeny a jak se chova v idealnim pripade, druha vec je co skutecne dokaze ustat v realnych podminkach.
-
toni (neregistrovaný)
"problem ZFS je ten, ze nema opravne nastroje"
To není pravda, ZFS má tzv. scrub, který kontroluje a případně opravuje data na zpoolu. Navíc ZFS automaticky opravuje chyby, které zjistí při běžném IO."nemit fsck.zfs je hloupost"
Tohle je asi věc názoru - mě naopak přijde jako hloupost chtít mít nástroj jako fsck, který funguje jen na neaktivním (odmountovaném) soborovém systému a čekat hodiny nebo i dny než doběhne. Takže jsem rád za scrub, který běží na pozadí."kazdy FS se muze pokazit"
100% souhlas, tesat do kamene."tak to smazali"
zkoušel jste založit Bug nebo request?"ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool"
Tohle není pravda, disky se do poolu samozřejmě přidávat dají. Je ale pravda, že v ZFS nelze přidávat disky do existujícího RAID-Z vdevu."bezi nad FreeBSD, coz je tajeno"
Jen pro zajímavost, kdo a jak to tají? Tohohle si přece musel všimnout každý, kdo někdy viděl NetApp alespoň bootovat. Navíc FreeBSD se pro podobné účely používá dost často (viz např. Isilon), takže se snad není za co stydět?"ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano)"
Kdo a jak to dokazal? Pokud máte na mysli ten spor NetApp vs Sun, tak pokud si správně vzpomínám, NetApp chtěl (1) zabránit tomu, aby Sun nabízel storage řešení založená na ZFS (pracovní stanice a general purpose servery byly ok) a (2) aby Sun nezveřejňoval zdrojáky ZFS a (3) nepodporoval další šíření ZFS. Spor byl urovnán a přesné pozadí asi nikdo z nás nezná, ale vzhledem k tomu, že Sun vzápětí zveřejnil zdrojáky ZFS, aktivně podporoval ZFS implementaci v Mac OS X a FreeBSD a začal prodávat storage boxy založené na ZFS (Sun Storage 7000), nedá se podle mě mluvit o nějakém drtivém vítězství NetAppu. Spíš bych to viděl na klasický patentový trolling. -
Adam KaliszStříbrný podporovatel
Jinak ke Sun Storage je docela dobrý tento: http://dtrace.org/blogs/bmc/2008/11/10/fishworks-now-it-can-be-told/ a tento: http://dtrace.org/blogs/ahl/2012/02/12/hardware-engineer/ článek. Happy reading
-
To ze na controlleru bezi BSD tajeno neni. U starsiho Ontapu kde je jeste 7-Mode je to naprosto zrejme. Novejsi verze s Cluster modem to trosku zakryvaji a z administrace to moc videt neni, ale staci se prihlasit primo na service processor nebo si pripojit seriovou consoli a koukat jak to bootuje.
Lidi z Netappu Vam informaci o BSD normalne reknout, zadne tajemstvi to neni.
Jinak technicky je to opravdu velmi vyspele reseni, je ta jejich podpora .... ta je obcas k vzteku :-(
-
Adam KaliszStříbrný podporovatel
Kompletně jiné paradigma. Shrnu to asi tak, že používáte výkon stroje na to, abyste data ukládal efektivně a více spolehlivě. Proto btrfs a ZFS používají Copy on Write, Checksum a podobné vymoženosti. Díky tomu můžete _ověřit_, že data, která jste uložil, budou skutečně navrácena v nezměněné podobě. No a když už máte kontrolní součet každého bloku, můžete poměrně snadno deduplikovat.
Umí to víc věcí, třeba právě integrace s volume managementem může být velkou výhodou při správě serverů. Knihy Michaela W. Lucase jsou dobrý začátek, když Vás ZFS zajímá. O btrfs byly přednášky na LinuxDays atp.
-
Problemy se spatnym vykonem ZFS (resp. jeho volume managementem), matoucim nastavenim quot, neustale chybejici disk space kvuli snapshotum a boot environmentum resime v praci (tady mluvim o domovskym systemu ZFS Solarisu) a neschopnost BTRFS ustat vypadek proudu sem resil doma nekolikrat, takze az zas tak me to nezajma.
Mel sem skoleni na ZFS primo od Oraclu, takze marketing znam a vim i jak vykonove neefektivni b-tree system s checksumem je.
Slo mi o to co konkretne pouzitelnyho tyhle novy b-tree systemy nabizej skutecne uzitecnyho oproti starsim casem proverenym b-tree systemum jako jsou XFS a JFS. Jestli jen checksum (coz dela disk tak jako tak nezavisle na filesystemu), deduplikaci (ktera je realne vyuzitelna snad jen pro IPS kde funguje jako binarni version control) a volume management, (ktery ma oproti SVM/LVM vykonovej deficit), tak fakt nechapu to nadseni kolem... -
vb (neregistrovaný)
Btrfs se zaměřuje na aktuální problémy Linuxu. Jedním z nich je systemd, ten pod Solarisem není. Přečtěte si
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html a pochopíte.U běžné konfigurace (např. samostatná pracovní stanice) systemd funguje, protože ta konfigurace je otestovaná. Když ale používáte konfigurace méně běžné (třeba NFS, LDAP), tak se může stát, že po změně konfigurace a rebootu se systemd zakousne a do systému se nedá dostat. Ani přes konzoli, ani přes síť ... Pak můžete trávit desítky minut odstraňováním problému v rescue módu, a nebo (když máte snapshoty), prostě jen nabootujete systém před provedením změny. Problém pak zkoumáte na jiném (ne produkčním) stroji.
Nicméně souhlasím s tím, že snapshoty žerou hodně místa. Výše zmiňovaná dokumentace uvádí, že btrfs je nastaveno jako default pro partitions se 16 GB. Já mám 32 GB a je to málo. Na "běžný" provoz to stačí, ale upgrade se na tom bez ručního mazání snapshotů dělat nedá. Na větším serveru jsem radši vyhradil 100 GB.
Pro uživatelská data openSUSE doporučuje XFS. Tady Btrfs žádné významné výhody nemá.
-
Trident (neregistrovaný)
My mame lepsi a s init zpetne kompatibilni SMF. A kdyz nam to spadne na tlamu recovery je rychle. I kdyz to nemuseli implementovat jako xmlkovy prujem... ale to je kvuli engineered systemum.
Vyreste si laskave problemy tam kde je mate resit - u systemd a nekravte dale system vytvarenim nesmyslnych zavislosti na dalsich komponentech.
Zrovna kvuli mamlasum tohoto typu jsem svou domovskou platformu - Linux opustil.
