On Thu, Aug 18, 2011 at 12:16:00AM -0600, Andreas Dilger wrote:

On 2011-08-16, at 9:25 PM, "Darrick J. Wong" [off-list ref] wrote:

quoted

- Extended attribute blocks that are stored in the inode table -- the h_magic
 field is written by the kernel, but neither the kernel nor e2fsprogs ever
 actually read this field.  The field could be reused to checksum the extra
 space since (as far as I can tell) EAs are the only user of that empty space.

I haven't had a chance to read the document you wrote, but wanted to comment
on xattrs. There is a hash field for each xattr (including internal xattrs),
and one for the external xattr blocks that can be used to validate the xattr
value.

In addition to the hash for the in-inode xattrs, the inode hash itself would
serve to validate the xattr values. 

I have a patch for e2fsprogs that checks the xattr hash for in-inode xattrs
(currently it is always 0).

I surveyed the h_hash/e_hash calculation code; it only covers the name and
value fields.  Do we care about checksum protection for the extra fields in
struct ext4_xattr_header and struct ext4_xattr_entry?  I think it would be
useful to be able to check the sanity of h_refcount and h_blocks.  Possibly
that extends to e_value_* as well, though the hash probably covers it.  Also,
there's no hardware acceleration available for the xattr hash, though I doubt
xattrs are especially performance sensitive.

--D

quoted

Please have a look at the design document and please feel free to suggest any
changes.

Hopefully soon. 

Cheers, Andreas--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html