Mac OS X Leopard nebude používat ZFS

Pro me byly nejvetsim lakadlem Leoparda dynamicke snapshoty ZFS. Kvuli tomu bych ihned switchnul.

Masox umi UFS2 ktery ma ficurky jako background fsck, dynamicky snapshoty a soft updates, takze kvuli tomu rozhodne nemusis cekat na zfs.

lenze pouzitim UFS2 prestane fungovat mnozstvo aplikacii a systemovych funkcii…

Jo?(apple nemam). ale na datovy partisne by to problem byt nemel ne?

to je tazko povedat. Problem s otvaranim suborov by nemal byt, avsak UFS2 nezvlada Macovske metadata takze Spotlight by toho moc na takom oddiely nenasiel. Tiez by nesli Mac OS X aliasy, teda ich volania dat na UFS2 by boli nefunkcne. Mac OS X pouziva 3 druhy linkovani – klasicke soft a hard linky z *nixovych OS a applacke vlastne aliasy – tie dokazu sledovat zmenu umiestnenia a nazvu povodneho suboru a nemusia sa prelinkovat. Toto na UFS2 v sucasnosti nie je mozne

z wiki

..ZFS is built on top of virtual storage pools called zpools. A pool is constructed from virtual devices (vdevs), each of which is either a raw device, a mirror (RAID 1) of one or more devices, or a RAID-Z group of two or more devices.

Apple is planning to use ZFS in future versions of Mac OS X, but not necessarily as the default filesystem for Mac OS X 10.5 Leopard.

pokial tomu rozumiem hlavná výhoda je že dokáže pracovať s veľa diskami a rozkladať záťaž, za behu pridávať dalšie disky, ale pre desktop, najmä ak máte len jeden disk to až taký prínos nemusí byť... osobne kľudne ostávam pri ext3, a keby som veľmi chcel tak si maximálne urobím RAID....

spis tohle:

Copy-on-write transactional model

ZFS uses a copy-on-write, transactional object model. All block pointers within the filesystem contain a 256-bit checksum of the target block which is verified when the block is read. Blocks containing active data are never overwritten in place; instead, a new block is allocated, modified data is written to it, and then any metadata blocks referencing it are similarly read, reallocated, and written. To reduce the overhead of this process, multiple updates are grouped into transaction groups, and an intent log is used when synchronous write semantics are required.

toto je už za hranicami mojich vedomostí, ale predsa:

to čo je tam popísané mi pripomína žurnál v ext3 (a prípadne inde), proste ide o to, aby filesystém prežil neočakávané vypnutie

dalšia vec je tu ten 256-bit checksum - ok to je uznávam je to dobrá kontrola konzistencie uložených dát, ale možno aj iné fs majú takéto niečo, nie?

Inak bolo by zaujímavé vedieť rýchlost zápisu/čítania/kopíriovania ak je tento fs na jednej partícií a v porovnaní s inými fs, prípadne veľkosť (%) réžie (diskový priestor ktorý využíva fs pre svoju potrebu) v porovnaní s inými fs, ako ext3 o ktorom sa hovorí, že ta réžia je tam príliš veľká

No prave ze to pokudvim nejournaluje, ale pouziva to ty checksumy(pokud sem to dobre pochopil). a tak by to mohlo byt o chlup rychlejsi.

inak predstav si kopirovanie veľkého objemu dát, pri čítaní aj pri zapisovaní musíš pre celý objem dát prepočítavať checksumy (ak kopíruješ z jedného ZFS do druhého ZFS), to môže byť dosť náročné na CPU. V každom prípade najlepšiu vypovedaciu hodnotu by mal nejaký benchmark, ja očakávam, že tento systém môže exelovať ak je na niekoľkých fyzických diskoch, ale na jednom disku/partícii môže byť naopak v niektorých veciach horší...

Aj to, že s tým prišiel SUN nasvedčuje skôr tomu, že ide o filesystém pre väčšie serverové multidiskové systémy

To by samozrejme bylo relativne narocny, ale musis si uvedomit ze nejslabsim clankem pocitace je disk. Proto si myslim ze zmenseni objemu prenasenech dat na ukor cpu. je jedine plus. Ale zas tak moc se v tom nevyznam.

Checksumy samotne by nestacili na uvedenie fs do konzistentneho stavu po pade systemu (zistilo by sa, ze je chyba, ale nie jak ju opravit). Zfs sice nepouziva "klasicky" journal, ale via copy-on-write - najprv sa zapise novy blok, a potom sa v metadatach zmenia pointery na novy blok (tak to postupne prebuble az do uberbloku).

Tym padom ak by sa system zosypal v strede zapisu, tak stare data zostanu neposkodene (pretoze sa este nezmenil pointer na blok, ktory este nebol dopisany). Celkom dobre je copy-on-write vidiet tu: http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf

Podobne to riesi s journalovanim aj Reiser4 + ma naviac nejake heuristiky, kedy nekopiruje bloky vzdy, kopirovanie ma zase nevyhodu, ze rozhadzuje bloky po disku (cim zvysuje seek time).

Co ma skor prekvapuje, je vyber SHA-256 ako checksumovacej funkcie (je to celkom kanon na vrabce a neni zrovna najrychlejsia). Aj ked je mozne zmenit na ine funkcie - fletcher2 a fletcher4, pripadne checksumovanie vypnut.

Uzivatele nemaji nadeji ze bude ve FreeBSD 7, je tam totiz uz nekolik mesicu. Neda se z nej akorat bootovat, ale to ostatne nedovede ani Solaris

ZFS by mohlo prave hezky primo podporovat time machine ... podle vyvojaru je podpora ZFS v developer verzich uz davno, takze predpokladam, ze se ZFS bude dat pouzit, jen nebude vychozi na bootovatelnem disku ... coz mozna souvisi s tim, ze se z nej zatim tusit bootovat neda z nejakeho duvodu

Tenhle filesystém by byl větší lákadlo než celý Time Machine.

Myslim, ze vetsina lidi spis vyuzije automaticke zalohovani nez zilionova diskova pole. Preci jen do koupenych Macu se obvykle uz nehrabe a na soucasne disky jeste HFS+ staci. Je tu moznost, ze bude ZFS pridan v nekterem setinovem updatu.

Ten filesystem neni vymecnej jenom svoji kapacitou, ale i dalsima vecma, viz wiki

Apple zklamal, no todle je opravdu hnus