I would also recommend this; well-written introduction, and talks a lot about the systems-issues that come up in games programming as well.

All true, except that copies can only be 1, 2, or 3; there's only room for three locations in a block pointer.

> I have no idea if they do this up front, inducing latency on all write operations, or as it goes.

All write IO is asynchronous, unless fsync() or O_DIRECT is used. The dedup check is done when the write goes out to stable storage (typically between 5 seconds and 60 seconds after the write is done).

The utility of this attack (which others have pointed out is pretty low until a SHA256-collision generator is done) is reduced by the fact that unless you are the first one in with a block, your collision will be thrown away (since it's a duplicate with the existing data).

So you would have to be able to predict the value which *will be written* and write out your attack block before the first version of the block you want to replace is written to the filesystem.

This doesn't make the attack useless, but it makes it much harder to pull off.

As the other poster said, you need to cite this. If the unrecoverable block is in user data, ZFS will return EIO when that block is read. If the unrecoverable block is in metadata, ZFS keeps at least 1 other copy of the metadata, so it will just read the other copy.

The same thing will happen if the checksum doesn't match.

It supports active directory, and user mapping between AD and LDAP. The CIFS stack is in-kernel.