> > => What if ZFS had parity blocks?
> > 
> > Try this scenario:
> > 
> > Given data to store, that data is stored in regular
> ZFS blocks, and a parity block is calculated. The
> data and parity blocks are laid out across the
> available disks in the pool.
> > 
> > When you need data from one of those blocks, only
> one block needs to be read to be able to calculate
> its checksum. If it is corrupt, the other data blocks
> and the parity block can be used to recreate its
> contents.
> 
> This seems identical to what raidz is doing, but
> you're somehow able to
> verify the contents of an individual disk block,
> something that you
> cannot do with the current raidz.  Presumably if
> there were room for
> multiple checksums in the parent pointer, you could
> checksum the
> individual raidz disk blocks rather than only the
> filesystem block.

Actually, no. RAID-Z is a zpool that takes the single block that the zfs layer 
is asking it to store, and splits it up across the storage.

In this scenario however, it's the zfs layer that generates the RAID layout, 
just like with ditto blocks.

So each block that you store is a regular zfs block that has a checksum. Take 
n-1 blocks of the same size, calculate a parity block and store that on the n 
disks.

> With ditto blocks, this isn't a problem.  The
> contents of each block are
> identical, so the checksum doesn't have to be stored
> individually.

Ok so you do need to keep track of which parity block belongs to which stripe. 
Is that a big problem?

> > On top of that, you would be able to store
> unrelated data blocks in the same stripe, thus
> ensuring maximum disk bandwidth and minimum parity
> size overhead.
> 
> Isn't that true today?

Well, I don't think so. The RAID-Z layer takes one block and stripes it as 
appropriate, it doesn't take multiple blocks and concatenate them, right?

Doing RAID in the ZFS layer seems like a much more ZFS way to do things...

Wout.
 
 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to