Vlákno názorů k článku
Pracuje se na APFS pro Linux
od pepik - Kdoví, v jakém to bude stavu. Škoda, že...
-
ZFS se v linuxu používat dá - dělám to denně a děkuju každej den lidem, co to dostali tak daleko. Truchlit nad neslučitelností licencí ničemu nepomůže. Důvody neshody obou stran jsou principiální a jejich pozice patrně zůstanou neměnné.
Nic lepšího než ZFS, co by šlo produkčně použít, jsem nenašel (prosím, nezačínejte flamewar). RedHat má připravovat nový filesystém založený na XFS + LVM, kdo by to hledal, jmenuje se to "Stratis". Doufám, že bude brzy dost stabilní, aby šel použít. Ze ZFS na něj ale přejdu, jen pokud mu budu opravdu věřit.
-
Ondra Satai NekolaZlatý podporovatelA není tohle poněkud specifický a možná trochu poťapaný usecase?
-
btrfs se nehodí ani na OS, ani na data. Jak píše kkt1, při velkých diskových polích to padá do kolen. Na druhou stranu čím dál více PB+ polí instalujeme na ext4, doba kdy jsme soubory ukládali přímo do FS je pryč a dnes je vhodnější je rovnou cpát do nějaké log-structured databáze a kompakce dělat řízeně než obtěžovat FS se správou stovek milionů souborů.
-
světový storage přeborník (neregistrovaný)
Ještě si vzpomínám na jedno z prvních videí od Sunu, když demonstrovali, že se ZFS nerozpadne při vytvoření pole na několika flash discích a při zápisu či čtení prostě libovolný z těch flash disků vytrhli ven, pak tuším druhý a pak je tam zase vraceli.
Btrfs jsem cca před rokem zkusil jenom jako mirroring na dva stejně velké HDD připojené přes usb (samozřejmě s checksumy atd.). Data se při zápisu ničila a analýzou příčiny jsem objevil nespolehlivé usb připojení u jednoho z disků (u druhého vše vypadalo OK). Co mně vyrazilo dech je fakt, že ani když jedno usb připojení zjevně fungovalo dobře, nepodařilo se data obnovit (a to šlo skutečně o obyčejné zrcadlení bez stripingu).
Tato zkušenost mě prostě poslala do kolen - takový (údajně) vymakaný filesystem a taková prkotina ho navždy rozbije (ani btrfs-check ani scrubbing atd. nepomohly). Možná se za ten rok btrfs posunul dále, ale již v té době byl dlouho mirroring a vůbec základní funkčnost (nic jiného jsem ani netestoval ani nepotřeboval) prohlášený za stabilní. Očekávám tedy, že chování bude nyní obdobně špatné.
-
z praxe vím, že btrfs prostě nepřežije zpravidla vypnutí natvrdo, občas se to ale u serverů stane, pak s tím je dost práce. Mám btrfs na mobilu a zatím se mi to ani jednou nerozbilo. Každopádně btrfs nepřežívá běžné DR akceptační testy, které mám u klientů, jiné FS to přežívají v pořádku, ono něco špatného uvnitř bude.
-
SUSE to má nahlášené v rámci placeného supportu s postupem a logy. Ano, je to nejspíš reprodukovatelné. Klasická věc, při zátěži vytahovat disky, vypínat servery, scénář je vždy podobný. Někdy to obnovit lze, ale délka obnovy bývá nad SLA, takže také špatně.
Vím, že někde používají btrfs pod clusterovou db a v případě problémů zahazují celý node a nesnaží se ho obnovovat, takovýhle scénář může také dávat smysl.
-
Petr Neni (neregistrovaný)
Co znamena nekdy to lze obnovit? Ze se udela repair, nebo ze to obnovujete ze zalohy, nebo..? SLA si definujete vy se zakaznikem a predpokladam, ze nemate SLA na jednotlive nody clusteru ale na sluzbu jako celek. Situaci, kdy vam spadne vsechno v DC mate obvykle poreseno zaloznim DC. A ohledne toho ze mount rozbiteho FS trva nejaky cas - to prave resite dalsimi nody klidne v jinem DC.
-
J ouda (neregistrovaný)
Dal jsem mu šanci dvakrát. Jednou (cca 4 roky nazpátek) to skončilo rozbitým filesystémem na mirroru (UPS, žádný HW problém, jen jeden restart natvrdo resetem, když se btrfs zbláznil a nic jiného nešlo, jinak vždy korektní shutdown s unmountem) tak, že nakonec jsem to musel vracet ze zálohy, podruhé šel do pryč když notebook po korektním shutdownu při bootu visel asi 5+minut při mountu btrfs zrovna když jsem potřeboval něco urgentně dělat (a odpovídající plnej fsck na ext4 na té samé partition s těma samejma datama asi 40 sekund).
