Názory k článku
Red Hat vydal RHEL 7.4
-
Ono to zní bombasticky, ale reálný dopad to nejspíš nebude mít vůbec žádný. RH nebyl vývojářem, sponzorem ani propagátorem BTRFS a jeho podpora nebo nepodpora v RHEL je tedy v zásadě irelevantní. Zkrátka je to bouře ve sklenici vody: firma, která absolutně nepoužívala BTRFS, ale uvažovala, že by ho někdy v budoucnu používat mohla, se nakonec rozhodna, že ho používat nebude. Co se stane? Nic. BTRFS se bude dál normálně vyvíjet, jeho uživatelé se nemusí ničeho obávat, každé nové vydání jádra přinese další bugfixy a novinky pro BTRFS tak jako dosud a RedHat v tom nebude hrát roli, tak jako ji nehrál doteď. Úplně absurdní jsou pak v této souvislosti řeči (hlavně na phoronixu) o ZFS, přitom RedHat nikdy ZFS nepodporoval ani o něm neuvažoval a v RHEL žádný ZFS nebyl, není a nebude.
-
Díky za vysvětlení!
Znamená to, že někdy v budoucnu už btrfs nebude výchozího jádra? Daná edice RHEL vždy po vydání zůstává u jedné verze jádra a dovedu si představit, že backportovat všech mnoho bugfixů btrfs je složité.
Pokud Red Hat nepodporuje ZFS, znamená to, že zůstávají u ext4? Proč jsou řeči o ZFS?
-
Adam KaliszStříbrný podporovatelBuď použít OpenZFS na vlastní triko, btrfs i přes to, že je deprecated a počítat s horší, ale existující podporou.
Do budoucna nejspíš vyvinou volitelné rozšíření XFS, které díky různým trikům s linky, cow a součty vlastně nahradí většinu slibovaných vlastností btrfs. Jenom volume management zůstane na mdadm a lvm. Časem asi jen na lvm. Nakonec tedy svět Linuxu dokonverguje k oddělení souborového systému od volíme managementu.
Docela jsem se divil, ale ta předtucha s XFS vypadá docela reálně. Třeba deduplikace by neměla být příliš daleko. Snapshoty XFS umí, takže spojením obojího by takový rudimenterni archiv bylo možné realizovat poměrně efektivně. Samozřejmě backup to nenahradí ani v jednom případě. -
dizzy (neregistrovaný)
no napriklad snapshoting v xfs sa momentalne da robit len ako dump celeho filesystemu (kompletny alebo incrementalny), takze potrebujete externe zariadenie, na ktore sa to vyleje. Cize momentalne sa to ani len omylom neda povazovat za ako-taku nahradu a este si teda riadne maknu aby sa dostali aspon tam, kde je btrfs (nehovoriac o tom, ze to bude treba riadne pretestovat, takze nez to bude povazovane za stable, moze kludne uplynut aj 10 rokov).
A co sa tyka oddelenia volume mgmt a filesystemu, tam si myslim, ze filesystem je docela kritickou castou OS a dokaze dost vyrazne profitovat z toho, ze vie na akom fyzickom mediu sa data ukladaju (nejde len o trim pre ssd, ale myslim, ze uplne inak by som optimalizoval ukladanie dat na klasicke HDD, inak na SSD, inak v pripade in-memory, atd). Cize skor si viem predstavit otocit volume management naruby, cize dole by boli zariadenia s filesystemom a nad nimi nejaky management, ktory by ich spojil do jedneho logickeho filesystemu a riesil by mirroring/stripping priamo nad jedn. subormi (nieco ako JBOD v HDFS).
Dost bolo ale fantazirovania - trocha som smutny z toho, ze RedHat odrezal btrfs bez toho, aby dal adekvatnu nahradu (a to, ze to mozem pouzivat aj nadalej je fajn pre sukromne ucely ale nie pre enterprise nasadenie v praci).
Docela by ma zaujimalo ako to bude vo Fedore, lebo pokial to neplanuju zarezat aj tam, je tu este mala nadej, ze ked sa btrfs konecne stabilizuje, tak sa k nemu mozno vratia...
