> 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/
