> Actually, the right question is "how is fuse better than coda". I've
> asked that before; unlike nfs, userspace filesystems implemented with
> coda actually *work*, but do not provide partial-file writes.
You answered your own question.
I did talk to Jan Harkes about the file I/O issue before starting
FUSE. [searching archives] here's a quote from him about this:
"I've been thinking about partial file accesses myself. However, I
really don't want to go all the way to block-level caching. That
would add a lot of overhead either in passing every read/write call
up to userspace, or by using a largish amount of memory to keep
track of availability of parts of the file. It also defeats the more
efficient 'streaming' fetch of a whole file.
However, something that would work reasonably well is a file offset
marker that indicates how much data is available. Basically, when the
application opens a file, the open upcall returns after the first...
let's say 64KB... have arrived. Any read's and write (and mmap's) that
access the available part of the file will be allowed. When any
operation tries to access beyond the marker an upcall is made which
blocks until the related part of the file has streamed in."
So true random access doesn't fit too well into the CODA philosophy.
Of course you could extend CODA to handle this as well (and all the
other things needed for safe user mounts), but the results would
proably not have pleased either side.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |