[tahoe-lafs-trac-stream] [tahoe-lafs] #1353: make the FUSE interface be a supported, first-class feature

[tahoe-lafs]

#1353: make the FUSE interface be a supported, first-class feature
-------------------------------+--------------------------------------------
     Reporter:  zooko          |       Owner:  somebody 
         Type:  enhancement    |      Status:  new      
     Priority:  major          |   Milestone:  undecided
    Component:  documentation  |     Version:  1.8.2    
   Resolution:                 |    Keywords:  fuse docs
Launchpad Bug:                 |  
-------------------------------+--------------------------------------------

Comment (by gdt):

 My use of the word kludgy was unhelpful, and I'd like to apologize for it.
 What I was trying to express is that to integrate tahoe into a VFS
 interface (so that it appears as a native filesystem) requires mapping the
 POSIX-ish VFS API to tahoe semantics.  The sftp interface does a lot of
 that, and it's particularly cool how the mutable/immutable divide is
 bridged.  Once you move from sftp client to VFS and think of VFS-based
 access being the dominant paradigm, then you start thinking "how do I do
 check" and "how do I get caps".   The answer seems likely to include a
 giant subroutine of "POSIX semantics are inadequate for distributed
 filesystems based on capabilities, so the VFS interface needs to be
 extended".  Already we've seen a proposal to use extended attributes for
 this, but perhaps new system calls are needed.  Once there are extensions,
 if there is a FUSE implementation, it needs to speak the new system calls
 and implement them via the WAPI or by being part of the tahoe process.
 With sftp, one would also need to extend the sftp/sftpd interface to
 support the new semantics.

 So, I'd like there to be a FS-independent check program, and one would say
 {{{
 check --repair foo
 }}}
 and that would do a system call which would get passed to the FUSE
 implementation, and that would translate to how tahoe does things.
 Someone using the FUSE module for some other massively distributed
 filesystem could use the same command, and it would be translated
 differently.  Perhaps on regular disks it would result in reading all the
 blocks to make sure they are there, and something similar could happen on
 coda and nfs.    Perhaps check/repair and lease renewal should be
 combined, and perhaps not.

 My other concern is that it doesn't currently seem possible to do the
 equivalent of "tahoe mount tahoe: ~/TAHOE" with sftp - I've only reduced
 it to a command that I then have to paste in a password.  But I realize
 this is a small matter of programming to remedy, and much easier than a
 whole FUSE implementation.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1353#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage