Jeff Bonwick said: > RAID-Z takes a different approach. We were designing a filesystem > as well, so we could make the block pointers as semantically rich > as we wanted. To that end, the block pointers in ZFS contains data > layout information. One nice side effect of this is that we don't > need fixed-width RAID stripes. If you have 4+1 RAID-Z, we'll store > 128k as 4x32k plus 32k of parity, just like any RAID system would. > But if you only need to store 3 sectors, we won't do a partial-stripe > update of an existing 5-wide stripe; instead, we'll just allocate > four sectors, and store the data and its parity. The stripe width > is variable on a per-block basis. And, although we don't support it > yet, so is the replication model. The rule for how to reconstruct > a given block is described explicitly in the block pointer, not > implicitly by the device configuration.
Thanks for the explanation - a great help in understanding how all this stuff fits together. Unfortunately I'm now less sure about why you cannot 'just' add another disk to a RAID-Z pool. Is this just a policy decision for the sake of keeping it simple, rather than a technical restriction? > If your free disk space might be used for single-copy data, > or might be used for mirrored data, then how much free space > do you have? Questions like that need to be answered, and > answered in ways that make sense. They need to be answered, but as the storage is scaled up we don't need any extra accuracy - knowing that a filesystem is somewhere around 80% full is just fine - I really don't need to care precisely how many blocks are free, and it actually hinders me if I get given the exact information (I have to scale it into the number of GB, or the percentage of space used). The fact that we then pretty much ignore exact block counts then leads me to think that we don't actually need to care about exactly how many blocks are free on a disk - so if I store N blocks of data it's acceptable for the number of free blocks to change by domething different to N. And once data starts to be compressed the direct correlation between the size of a file and the amount of disk space it uses goes away in any case. All pretty exciting - how long are we going to have to wait for this? Steve. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
