[tahoe-dev] Tahoe-LAFS is widely misunderstood

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Feb 4 08:48:49 UTC 2011


On 2011-02-03 20:50, Scott Dial wrote:
> On 2/3/2011 1:44 AM, Chris Palmer wrote:
>> Scott Dial writes:
>>> % attr -g writecap .
>>> URI:DIR2:xxx...:yyy...
>>> % attr -g readcap .
>>> URI:DIR2-RO:xxx...:yyy...
>>> % attr -g verifycap .
>>> URI:DIR2-Verifier:xxx...:yyy...
>>
>> What platform do you do this on? On Ubuntu, attr(1) is a non-default package
>> and is specific to XFS; getfattr(1) and setfattr(1) are present but the
>> default ext3 configuration does not have option user_xattr.
>>
> 
> You're right. I misremembered the commands. "attr" is the XFS variation
> of the same thing (except that attr prepends a "user." or "root." prefix
> to the name before calling getxattr() in order to make distinct
> namespaces for users and superusers). "getfattr" is the more standard
> tool. So, the proper snippet should've been:
> 
> % getfattr -n readcap .
> # file: .
> readcap="URI:DIR2-RO:xxx...:yyy..."
> 
> And I think it's quite powerful to be able to do:
> 
> % tahoe check `getfattr -n readcap --only-values somefile`
> Summary: Healthy
>   storage index: qggq5w4ynbxo6x2ns3ydv3uyq4
>   good-shares: 12 (encoding is 3-of-12)
>   wrong-shares: 0

Even better, we could make that just:

  tahoe check somefile

by having 'tahoe check' call getxattr(2).

However, this is only reasonable if we know that 'somefile' is in a
Tahoe filesystem, and more specifically that it is in the same Tahoe
grid referred to by the node directory for 'tahoe check'.

(The "readcap" attribute could be set to anything for files in non-Tahoe
filesystems, either maliciously or accidentally. This could happen
accidentally if you copy a Tahoe file to a non-Tahoe filesystem
preserving attributes. Also, an URI represents a capability only within
the context of a specific grid.)

It is probably OK if we restrict this to working when the new
'tahoe mount' command (http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1357)
has been used to mount the filesystem, and 'tahoe check' is using the
same node directory as 'tahoe mount'. Otherwise the grid check is probably
too hard to implement.

Here's how to get the mount point for a path:
<http://stackoverflow.com/questions/1138383/python-get-mount-point-on-windows-or-linux>

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110204/d78e031d/attachment.asc>


More information about the tahoe-dev mailing list