[tahoe-dev] [tahoe-lafs] #1351: Use extended attributes to expose metadata

[tahoe-lafs]

#1351: Use extended attributes to expose metadata
------------------------------------------+---------------------------------
 Reporter:  ScottD                        |           Owner:  somebody 
     Type:  enhancement                   |          Status:  new      
 Priority:  minor                         |       Milestone:  undecided
Component:  code                          |         Version:  1.8.2    
 Keywords:  fuse metadata unix usability  |   Launchpad Bug:           
------------------------------------------+---------------------------------
 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.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1351>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage