[tahoe-dev] Owncloud / Tahoe

[Greg Troxel]

"Zooko O'Whielacronx" <zookog at gmail.com> writes:

> The specific problem with accessing Tahoe-LAFS through a POSIX API is
> that it might require uploading many copies of a file in order to
> emulate the POSIX semantics. For example, imagine an app that opens a
> large file, edits the last 20 bytes of the file, and closes it, over
> and over. With the current Tahoe-LAFS POSIX emulation, this will
> require uploading a complete copy of the entire file, no matter how
> big it is, every time the app closes the file. This will probably lead
> to a timeout, or at least be unusable, as well as filling up your
> Tahoe-LAFS storage server with useless old copies.

Sure, that'a a reason why some use cases will not be happy.  But those
problems apply to a fuse-mounted SFTP setup.  It's really an argument
that immutable files only really work for users that have an
immutable-friendly workload - which might be about making mutable files
the default.

> Here's my latest attempt to document this in the FAQ, prompted by this
> conversation:
>
> https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ#Q23_FUSE

Fair points.  I'm not suggesting that once there is great FUSE support
that people should use it like a regular FS.  What I mean to say instead
is that the VFS operations are the standard approach and that even if
one is staying within the operation styles that work, it's useful to
have the common interface.

> Anyway, I wouldn't be surprised if ownCloud has similar, or different,
> impedance mismatches which prevent certain use cases from working
> through FUSE with ownCloud, in which case whoever is using their apps
> with ownCloud through FUSE could use them just as well with Tahoe-LAFS
> through FUSE. So, if that guess is right, then this would be a case
> where my specific warning against a POSIX emulation layer doesn't
> apply.

I think that's probably the case.  owncloud has a web-based
upload/download that should work fine, and also webdav and other file
access protocols.

Interestingly, coda has a similar whole-file write issue even though it
isn't really intrinsic to the fs design.  Even opening for write and
closing results in a store operation.  However, the support for
disconnected operation results in coalescing of stores.

> But, I suppose this is all guesswork and imagination until someone
> tries using it this way and reports back.

Indeed.  My point is really that the fact that an interface could be
used in a way that provokes bad behavior isn't a reason to not have the
interface.  There are lots of uses that won't have this problem, and I
suspect putting BUPDIR on vfs/tahoe would be an ok use.

It's also fair to ask for real experience.  Working with pyfilesystem is
on my eventual-todo list.

I wonder how much of this mismatch is due to immutable files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130423/6b29396b/attachment.pgp>