On Thu, Nov 05, 2009 at 11:55:58AM -0800, Ilya wrote: > Slide 18 shows variably sizes extents but doesn't explain the process > of full-on write. What I'm looking for is one example. I still don't > understand how it works with variable sized extents. So if you have 2 > stripe units on one disk and 1 stripe unit for the parity and you > modify half of the first stripe unit only, when you do a full-stripe > write, what happens in terms of a full-stripe write?
You never modify a ZFS block (or part of a ZFS block). You write a new replacement block elsewhere and a new metadata tree is constructed that references the new block and not the old one (other than via snapshots). I'm not sure I understand your picture of "2 stripe units on one disk and 1 stripe unit for parity". That doesn't seem correct. Are you looking at a particular portion of that graphic that you could reference? > I also didn't see a distinction between parity and metadata > reconstruction. I still do not know the process behind the metadata > reconstruction for bad data and when parity is used for bad data. Not sure what you mean by metadata reconstruction. The checksums stored in parent blocks can be used to validate child blocks (either metadata or data). If the checksum fails, and there is redundant information (copy, parity, mirror), then the system tries to see if the data is available through the redundant data. It will read the other half of the mirror, or try to read a data using a parity reconstruction. It will then validate that other read via the checksum. If that checksum succeeds, you've read the data and the system should attempt to rewrite the redundant info (assuming it was a bad block and not a disk failure that has left the pool in a degraded state). If the checksum fails and there is no redundant copy, then the data is not returned. -- Darren _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
