Extended attributes

Posted Jan 3, 2019 22:38 UTC (Thu) by foom (subscriber, #14868)
In reply to: Extended attributes by TheGopher
Parent article: A setback for fs-verity

A generic mechanism would seem to be a better idea...

But, to make xattrs support large data would effectively also require creating a brand new mechanism. It's not quite simple. As the tip of the iceberg, "getxattr" and "setxattr" can only deal with the entire value at once -- not a good idea for a large data stream.

However, other OSes do support this sort of thing, allowing "forks" of the file to be opened for reading/writing just as a normal file. E.g., Windows NTFS has "alternate data streams", and Solaris has "fsattr". (https://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02/)

to post comments

Extended attributes

Posted Jan 4, 2019 8:43 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

That doesn’t really help, since the alternate data streams can be used by applications, so the fs-verity Merkle tree needs to be for the whole file, including all its forks?

Extended attributes

Posted Jan 4, 2019 9:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Merkle tree is self-verifying, so it doesn't need to be further checksummed.

Extended attributes

Posted Jan 5, 2019 21:22 UTC (Sat) by epa (subscriber, #39769) [Link] (1 responses)

What I mean is that since the alternate data streams are exposed to user space, each one needs its Merkle tree. So it would appear you need to implement the verifying at some lower level of filesystem code where you are dealing with a single piece of data. Either that or generalize it to add one extra steam for each stream that exists - and then arrange to hide these extra ones from user space.

Extended attributes

Posted Jan 7, 2019 2:40 UTC (Mon) by marcH (subscriber, #57642) [Link]

> or generalize it to add one extra steam for each stream that exists

Sounds good.

> and then arrange to hide these extra ones from user space.

Why? Aren't stream typed on some way?