-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, everybody. I have a question about the inner working of ZFS. Hope somebody can provide some light. ZFS keeps 128 uberblocks around, just in case the last transactions are corrupted for any reason. My question is about block freeing. When a file is deleted, its block are freed, and that situation is committed in the next txg. Fine. Now those blocks are free, and can be used in new block requests. Now new requests come and the (now free) blocks are reused for new data. But what if something fails and when we reboot the last uberblocks are bad and we have to "force" to use an old uberblock. Now we could have the original file "corrupted" with data from another file. Asking around, some people says "the freeing is delayed for a while". That reply is not satisfying, because it seems to be especulative, "a while" is not helpful, and the algorithm is not clear. Any idea?. This bugs me a lot, but I rather prefer do not look to ZFS code... Thanks!. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTMrKR5lgi5GaxT1NAQL89QP5ASKxVb025N2jX5MTfYKR2OIbuLPUa5E9 IAS9Nkqfdh8VpnxG+RM/vmpbmxhlAwxQZZvktMmGAgo4YX/P7xwnyj0MJm+sxj0S Mltu6BLrvUnabrlSNJpjLNpbhz7irY6UkfrJa5O2hkjaZJW0uwJhPmjVtxd7Y/zb 5MTjlkwD4X8=RNZX -----END PGP SIGNATURE-----
On Oct 29, 2010, at 9:21 AM, Jesus Cea wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, everybody. > > I have a question about the inner working of ZFS. Hope somebody can > provide some light. > > ZFS keeps 128 uberblocks around, just in case the last transactions are > corrupted for any reason. > > My question is about block freeing. > > When a file is deleted, its block are freed, and that situation is > committed in the next txg. Fine. Now those blocks are free, and can be > used in new block requests. Now new requests come and the (now free) > blocks are reused for new data.ZFS will not reuse blocks for 3 transaction groups. This is why uberblock rollback will do normally only attempt a rollback of up to two previous txgs. - Eric -- Eric Schrock, Fishworks http://blogs.sun.com/eschrock
On Fri, October 29, 2010 10:00, Eric Schrock wrote:> > On Oct 29, 2010, at 9:21 AM, Jesus Cea wrote: > >> When a file is deleted, its block are freed, and that situation is >> committed in the next txg. Fine. Now those blocks are free, and can be >> used in new block requests. Now new requests come and the (now free) >> blocks are reused for new data. > > ZFS will not reuse blocks for 3 transaction groups. This is why uberblock > rollback will do normally only attempt a rollback of up to two previous > txgs.Just curious: is is run-time tunable, or hard-coded in at compile time?
This value is hard-coded in. - George On Fri, Oct 29, 2010 at 9:58 AM, David Magda <dmagda at ee.ryerson.ca> wrote:> On Fri, October 29, 2010 10:00, Eric Schrock wrote: > > > > On Oct 29, 2010, at 9:21 AM, Jesus Cea wrote: > > > >> When a file is deleted, its block are freed, and that situation is > >> committed in the next txg. Fine. Now those blocks are free, and can be > >> used in new block requests. Now new requests come and the (now free) > >> blocks are reused for new data. > > > > ZFS will not reuse blocks for 3 transaction groups. This is why > uberblock > > rollback will do normally only attempt a rollback of up to two previous > > txgs. > > Just curious: is is run-time tunable, or hard-coded in at compile time? > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101029/87a4684b/attachment.html>