Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
Dik :)
W.
On Tue, Jan 10, 2017, at 19:01, Wolf wrote:
Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
třeba raidz, který nezpůsobuje poškození filesystému... ;) https://www.phoronix.com/scan.php?page=news_item&px=Btrfs-RAID56-Not-All...
Dik :)
W.
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
On , Daniel Kolesa wrote:
třeba raidz, který nezpůsobuje poškození filesystému... ;) https://www.phoronix.com/scan.php?page=news_item&px=Btrfs-RAID56-Not-All...
yep, musim uznat, ze podpora raid5/6 by byla hezka, preci jenom je pak vice mista.
T.
No v prvni rade vykon…
Rozdilu tam je vic:
1. ZFS umi storage tiering (L2ARC). Sice muzes namitnout ze existuje bcache a podobny ale tu podle mejch zkusenosti rozhodne nelze povazovat za stabilni a dostatecne rychlou. Dalsi ruzny pokusy o tiering ve vrstve device mapperu jsou na tom podobne.
2. ARC cache misto LRU. LRU jako algoritmus patri do propadliste dejin, ale diky z myho pohledu nesmyslenjm zabomysim valkam vyvojaru Linuxovyho jadra tam je porad. Na dnesnich strojich s desitkama GB RAM je LRU proste v p….. Viz: https://en.wikipedia.org/wiki/Cache_replacement_policies
3. Oproti BTRFS stabilnejsi implementace (tim nechci rozhodne rict ze ZFS na linuxu je z hlediska stability vyhra, ale oproti BTRFS je na tom lip - kdyz BTRFS se velmi rychle vyviji).
Ale abych nechvalil jsen ZFS tak BTRFS ma z meho pohledu lepsi navrh - zejmena podpora zpetnejch referenci ktera umoznuje pohodlne defragmentovat, zmensovat, menit uroven redundance a dalsi. Ale ikdyz je v principu navrh lepsi, tak ma mnohem slozitejsi implementaci a nez bude BTRFS pripravene pro produkcni nasazeni a zejmena dosahne i odpovidajiciho vykonu tak to bude proste jeste chvili trvat.
Za mne osobne - BTRFS pouzivam a libi se mi, ma z myho pohledu daleko lepsi praci se snapshoty (opet vychazi z podpory zpetnejch referenci). Ale mam ho napriklad na malo zatizenejch diskovejch polich na ruznych serverech kam ukladam zalohy (rsync + snapshot je proste parada). Ale tam kde hodne honim vykon (napr. velmi vytizeny NFS servery atd tak tam slo ZFS - a v mym pripade ale pod FreeBSD protoze tam je ta implementace o neco zralejsi nez v Linuxu coz je dano tim ze jadro *BSD je Solarisimu daleko bliz, zejmena z pohledu spravy pameti).
— Stanislav Petr
- 2017 v 19:01, Wolf wolf@wolfsden.cz:
Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
Dik :)
W.
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
psnajder dělal o tom přednášku před rokem na Linux days. Nevím jestli je někde video. Myslím si, že nejlepší shrnutí, je že ZFS jíž roky umí stabilně dělat věcí o kterém BTRFS jen nedávno začalo snít.
Tim
On 01/10/2017 19:01, Wolf wrote:
Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
Dik :)
W.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
fuu, Ked si toto snajpa precita tak sa mu isto zdvihne žlč :D kazdopadne https://www.youtube.com/watch?v=yxcYRmBG6Y4 https://www.youtube.com/watch?v=yxcYRmBG6Y4
tm
On 10 Jan 2017, at 19:01, Wolf wolf@wolfsden.cz wrote:
Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
Dik :)
W.
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Nezvedlo mi to nic, neboj ;)
Nejzasadnejsi rozdil mezi BTRFS a ZFS neni v kodu, ani v navrhu, ale je v pristupu vyvojaru.
ZFS ma od zacatku byt komplexni reseni pro ukladani dat za predpokladu, ze tech dat bude fakt hodne (at uz v absolutnich cislech, nebo obrovska mnozstvi souboru/adresaru).
Podle toho se v nem delaji navrhova rozhodnuti a podle toho obsahuje featury.
BTRFS je oproti tomu jenom filesystem a k tomu FS bez valne vize - vetsina vize BTRFS je "chceme featury, co ma ZFS uz davno, ale po svem a flexibilneji" - jako s vetsinou featur, co se toci okolo Linux kernelu - teoreticky navrh je mnohem prednejsi pred implementaci a podle toho to pak vypada.
Ale v pohode, to se vychyta; ZFS nebylo taky pouzitelne hned - proto treba nema backreference, jak pise Standa - je to naprosto vedome rozhodnuti, ktere usetrilo cca 50% kodu kvuli minoritnim use-cases (vetsinou stejne napr. preskladani pole za jinou konfiguraci resi clovek s jednim a pul disku, ne kdyz mate 2 patra racku...).
ZFS zacalo jako napad nekdy v roce 2000 a v roce 2005 bylo shippovane produkcne zakaznikum. Resi naprosto realne problemy svych uzivatelu, kteri by jinak poradne nemeli jak se o takova mnozstvi dat starat. Jak dlouho je ve vyvoji BTRFS a jak dlouho se na podobnou pripravenost k produkci bude cekat u nej?
Jak jsem psal, ZFS je storage system, BTRFS je filesystem. Z toho pohledu BTRFS nikdy nebude resit veci, co ZFS poklada za "svuj problem" - napr. sprava cachingu, ale i veci okolo jako nastavovani shares (nfs/smb/iscsi), vlastni IO scheduler, atd.
A jinak k tomu, co psal Standa o SPL - sice to vypada strasidelne, ale primarni problem vubec neni v tom, ze by Linuxova semantika funkci okolo spravy pameti byla nejak turbo odlisna. Je odlisna na par mistech, to je pravda; ale primarni rozdil zase neni v kodu, ani v navrhu (kteryzto, btw, velke prekvapeni, je zase puvodem ze Solarisu, protoze SLAB cache je puvodem ditko Sunu...).
Rozdil je v tom, jak se pamet v kernelu pouziva. V Linuxu v podstate neexistoval do doby techhle filesystemu zadny vetsi consumer SLAB pameti a proto SLAB stoji tak za *piiip*. Jednoduse na neco takoveho zas nebylo navrzeno a testovano.
Ale zase, dela se na tom a zlepsuje se to.
Jak s oblibou rikam, treba RHEL 8 konecne featurove dozene Solaris 11...
/snajpa (Pavel Snajdr) (Predseda vpsFree.cz) (+420 720 107 791)
On 01/10/2017 07:49 PM, Tomas Meszaros wrote:
fuu, Ked si toto snajpa precita tak sa mu isto zdvihne žlč :D kazdopadne https://www.youtube.com/watch?v=yxcYRmBG6Y4
tm
On 10 Jan 2017, at 19:01, Wolf <wolf@wolfsden.cz mailto:wolf@wolfsden.cz> wrote:
Ahoj, muzeme mi nekde z tech, co do toho vidi vice nez ja rici, proc vlastne pouzivame ZFS misto treba BTRFS?
Tento mail neni pokus o flame war, pouze mne zajima, jake features ZFS ma a BTRFS ne. Nebo je to vec historicka, tedy ze ZFS umelo co potrebujeme drive ale dnes by slo nahradit (tim netvrdim, ze by se to melo udelat)?
Dik :)
W.
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Daniel Kolesa -
Pavel Snajdr -
Stanislav Petr -
Timothy Hobbs -
Tomas Meszaros -
Wolf