Journaling soft updates
2010.01.05. 11:22
Wattafuck? Korábban évekig ment a vita a (populárisabb, Free-)BSD-s és a linuxos arcok között, hogy most akkor melyik a jobb, a journaling, vagy a soft updates?
Persze a démonos oldalon túl sok választás nem volt, az ördög ügyvédjének muszáj volt a szoft updatest szeretnie, ellenkező esetben akár azt is mondhatta volna, hogy a Linux a jobb. Márpedig ez megengedhetetlen.
Aztán a vita valahogy alábbhagyott, pedig egy csomó "advanked" fájrendszert (sic, amúgy xfs, reiser"killer"fs) beleszuszakoltak a FreeBSD-be, de csak amolyan tessék-lássék (read only) módon, amikor pedig megérkezett a ZFS is, a vitára úgy tűnt, hogy örökre keresztet vethetünk.
De úgy látszik mégsem, van, akinek nem jó a ZFS (beágyazott rendszereknél mondjuk el is tudom hinni), így az iXsystems, Yahoo!, és Juniper networks kooprodukcióban megérkezni látszik a journaling soft updates a FreeBSD-s UFS-hez.
Jeff Roberson (a szerző), blogjában osztja meg a részleteket, hogyaszongyja:
Soft-updates guarantees that the only filesystem inconsistencies on unclean shutdown are leaked blocks and inodes. To resolve this you can run a background fsck or you can ignore it until you start to run out of space. We also could've written a mark and sweep garbage collector but never did. Ultimately, the bgfsck is too expensive and people did not like the uncertainty of not having run fsck. To resolve these issues, I have added a small journal to softupdates. However, I only have to journal block allocation and free, and inode link count changes since softdep guarantees the rest. My journal records are each only 32bytes which is incredibly compact compared to any other journaling solution. We still get the great concurrency and ability to ignore writes which have been canceled by new operations. But now we have recovery time that is around 2 seconds per megabyte of journal in-use. That's 32,768 blocks allocated, files created, links added, etc. per megabyte of journal.
Na igen, a bgfsck tényleg nem volt egy szerencsés elképzelés, meg aztán TB felett már úgy általában az fsck sem az, milyen dolog már, hogy egy kisebb fájlrendszer fsck-zásához már 64 bites CPU kell, hogy a szükséges RAM-ot meg tudja címezni a rendszer...
Szóval úgy tűnik a ZFS mellett UFS fronton is lesz még némi fejlesztés...
Ajánlott bejegyzések:
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
Trevize 2010.01.05. 13:44:02
Boldog Új Évet!
Vártam már a kommentjeidet, nyilván Neked is nagy rakás munkád volt így év vége fele.
</on>
blackshepherd · http://suckit.blog.hu 2010.01.05. 15:23:26
Valóban kicsit elhavazódtam, aztán jött rá a fagyás. :)
lolcode · http://isten.aldja.szalaiannamari.at 2010.01.05. 23:17:18
soft updatesel meg nem vesztettem adatot :)