Use extended attributes to expose metadata

[ScottD]

A number of users want to be able to mount Tahoe dircaps into their file system (via FUSE, for instance). Once mounted this way, it becomes difficult and error-prone to retrieve any metadata that Tahoe has about files and directories (e.g. a read-only cap).

One way that this could be made better would be to expose those values as extended attributes in the file system. For instance, FUSE supports getxattr, which could be used for this purpose. For instance,

% getfattr -n readcap /mnt/pubgrid
# file: /mnt/pubgrid
readcap="URI:DIR2-RO:xxx...:yyy..."

At the moment, Tahoe does not support storing extended attributes, so there are no conflicts. However, ticket:947 proposes to add support for storing extended attributes to Tahoe, which would create a namespace conflict for this enhancement. Despite that, we could reserve a prefix for attributes (e.g., "tahoe.readcap") and raise an error/warning when such an attribute is asked to be stored.

There are currently a few different implementations of Tahoe where a specification for getxattr would be useful. We have a couple FUSE implementations in the source tree and the TahoeFS implementation in PyFS (ticket:1111) can expose extended attributes in a variety of ways.

I have personally patched PyFS to expose attributes like I have described and find it useful. Where "useful" means that I previously punted entirely on using readonly/verify caps because they were too difficult to retrieve. Additionally, being able to retrieve caps like this allows perform other "tahoe" commands with ease:

% tahoe check `getfattr -n readcap --only-values somefile`
Summary: Healthy
 storage index: qggq5w4ynbxo6x2ns3ydv3uyq4
 good-shares: 12 (encoding is 3-of-12)
 wrong-shares: 0

As and aside, if we reserved a prefix like "tahoe." for extended attributes, then we could even make "tahoe" aware of these attributes to create a shortcut around running "getfattr".

Prior to pushing this into my local version of PyFS, I would've had to resort to the WUI and copy/pasting sensitive data, which means I just didn't.

[davidsarah]

Replying to ScottD:

% getfattr -n readcap /mnt/pubgrid
# file: /mnt/pubgrid
readcap="URI:DIR2-RO:xxx...:yyy..."

At the moment, Tahoe does not support storing extended attributes, so there are no conflicts. However, ticket:947 proposes to add support for storing extended attributes to Tahoe, which would create a namespace conflict for this enhancement. Despite that, we could reserve a prefix for attributes (e.g., "tahoe.readcap") and raise an error/warning when such an attribute is asked to be stored.

Jan-Benedict Glaw wrote on tahoe-dev:

Well, maybe even storing a cap is useful! After all, it would be kind of a combined link/rename operation for some unrelated file/directory.

Other than that, xattrs used in that way are a swiss army knife to interact with Tahoe-LAFS internals in a FUSEd environment.

Perhaps, but note that sshfs does not support extended attributes. FUSE-via-sshfs is currently the most functional and the best-supported and tested FUSE interface to Tahoe.

[davidsarah]

Replying to davidsarah:

Replying to ScottD:

% getfattr -n readcap /mnt/pubgrid
# file: /mnt/pubgrid
readcap="URI:DIR2-RO:xxx...:yyy..."

At the moment, Tahoe does not support storing extended attributes, so there are no conflicts. However, ticket:947 proposes to add support for storing extended attributes to Tahoe, which would create a namespace conflict for this enhancement. Despite that, we could reserve a prefix for attributes (e.g., "tahoe.readcap") and raise an error/warning when such an attribute is asked to be stored.

Jan-Benedict Glaw wrote on tahoe-dev:

Well, maybe even storing a cap is useful! After all, it would be kind of a combined link/rename operation for some unrelated file/directory.

On closer examination this isn't a good idea. The problem is that copying with preservation of attributes, for example using ​cp --preserve=xattr on Linux, would cause the destination of the copy to be aliased to the source. That is harmless for immutable files on the same grid (because the source and destination would already have converged), but very wrong for mutable files and directories. For immutable directories on the same grid it is more subtly wrong: a recursive copy of an immutable directory would create a mutable copy, then discard it and make the destination point to the original, resulting in a space leak at best (which would be temporary when GC is used, but still undesirable), or loss of data if the destination already existed. For immutable files/directories on different grids (e.g. under different mount points), it is also wrong because the source cap won't be valid for the destination.

Preservation of extended attributes is the default behaviour for ​cp on Mac OS X.

[ScottD]

Replying to davidsarah:

On closer examination this isn't a good idea.

I never suggested that setxattr(2) work, and if it did: I would suggest that it silently ignore the setting of these special attributes. That would allow naive copying of xattrs without causing strange behaviors. It's already the case that there are filesystems for which you cannot set all attributes and the copying of some attributes is nonsense (see ticket:1228 which talks about some of those attributes for ext4).

[davidsarah]

Replying to ScottD:

Replying to davidsarah:

On closer examination this isn't a good idea.

I never suggested that setxattr(2) work ...

Right, I was replying to Jan-Benedict Glaw's comment.

and if it did: I would suggest that it silently ignore the setting of these special attributes. That would allow naive copying of xattrs without causing strange behaviors.

That seems reasonable.