Se ZFS bych se osobně nezabýval.. nepřijde mi to pro domácí server ničím zásadně zajímavé..
Je to zásadně zajímavé několika věcmi.
Jasně, je to pokročilý souborový systém 21. století atp.. Checksumy, COW, prevence write hole, flexibilní pooly.. Dokážu si představit, že to někde bude fakt excelentní volba.
Nicméně pragmaticky vzato.. ve většině případů (teď mluvím v kontextu domácího NASu, přesně jak jsi zmínil.. Terabytová hromada torrentů se seriály a filmy, možná stovky GB fotek, desítky GB muziky, která je z 95% na Spotify a pár stovek MB dokumentů.. vše na jednom velkém sdíleném disku) je to podle mě overkill.
Někdo o tom možná ze začátku uvažuje tak, že to bude postupně nafukovat a každý rok kupovat další disk nebo tak.. Nevím, vždycky mi nejlíp spolehlivostně vycházelo - chvíli počkat s investicí, koupit všechno najednou, stejně staré disky z jedné série se stejným FW, dát jim na začátku trochu záhul (třeba pomocí badblocks z e2fsprogs), zkontrolovat SMARTy a případně vyreklamovat slabší kusy.. Pak nakonfigurovat RAID, vyhnout se různým kritickým operacím (např. expanzím bez baterek a UPS) a ideálně za pět let všechno komplet otočit.. Kritická data (fotky, dokumenty) pak průběžně šoupat třeba na další externí disk..
Další osobní argument jsou potenciální kritické situace.. subsystém md-raid je poměrně konzervativní a odladěný, jsou dobře popsány různé záchrané operace.. Podporuje jej přímo většina spec. programů na záchranu dat.
Dá se z toho i svépomocí docela dobře dostat.. Např. manuální sesazení RAIDu po HW selhání dvou disků v R5, pokud se např. podaří jeden z nich v nějaké podobě stáhnout do image po výměně elektroniky nebo rekalibraci offsetu hlaviček.. Neříkám, že neexistují nějací guru na ZFS, co s tímhle také nemají problém.. ale kvůli jeho malé rozšířenosti to bude o mnoho težší (nebo ukrutně drahé)..
Takže mi to osobně přijde spíš vhodné pro lidi, co si chtějí vyloženě hrát (naučit) se ZFS.. každý týden přidat nebo ubrat jeden zpool atp. Asi v podobném duchu jako, rozběhat si ve FreeBSD v linuxové emulaci Oracle se všemi jeho závislostmi a finálně si v ní udělat repliku ukázkové databáze NorthWind
. I když vlastně pro to mám osobně docela pochopení..
týden trvající resliveringy atp.
Cože? ZFS má právě oproti normálním RAIDům (sw i hw) právě tu výhodu, že resilveruje jenom to, co je opravdu potřeba. Potřebný čas se tím právě dramaticky zkrátí.
Jj, principiálně samozřejmě souhlasím, kopírují se jen bloky, co jsou potřeba.
Ja jsem vycházel z realné zkušenosti s dvěma NAS na ZFS u kamarádů, kde se měnily 2TB disky, před pár lety. Opravdu to bylo pekelně pomalé, zvlášť na nějaké slabší konfiguraci (Celeron, Nkové ATOMy).. co si vybavuji, tak jsme zkoušeli i tweak některých parametrů delay, min_time_ms.. to trochu pomohlo, ale rychlost stejně vzrostla na pár MB/s
Což je úplně neporovnatelné (chápu i principiálně) s rychlostí resyncu u softwarového md-raidu..
Možná na nějakém rychlém serveru s lepšími výkonem je to jiná káva.. tohle byly pro mě "domácí" NASy v klasickém slova smyslu..
NASy založené na FreeBSD, jako je FreeNAS, jsou sice oddladěné i se ZFS, ale zároveň se tam dá občas narazit na problémy s omezením v některých aplikacích.. Např. DLNA servery dokáží automaticky aktualizovat svou databázi po přidání nového souboru, protože používají na Linuxu inotify. Na FreeBSD je sice obdobná možnost s kqueue, ale žádný z běžně rozšířených DLNA serverů jej nepoužívá, takže nezbývá než periodicky proskenovávat všechny soubory s médii.
KQUEUE=on: Experimental patch for automatic rescan using kqueue(2)
https://www.freshports.org/net/minidlna/
Ten patch byl původně poslán na sourceforge stránku od MiniDLNA.. zkoušel jsem jej vícekrát v několika verzích, ale pak jsem to vzdal.. FreeNAS byl kamaráda, kterému jsem to řešil. Mělo to s patchem tendence dost často padat, případně selektivně ignorovat soubory v knihovně. Finálně tam skončil MediaTomb, který sice nebyl ideální z jiných důvodů.. ale alespoň umožňoval spuštění manuálního rescanu u složky přes své webové rozhraní.
85 Odpovědí
20315 Zhlédnutí