From: Goswin v. B. <gos...@we...> - 2010-01-21 19:03:49
|
John Muir <jo...@jm...> writes: > On 2010-01-14, at 8:20 AM, Miklos Szeredi wrote: >>>>>> ]Is it possible to activate a write-cache in the FUSE kernel module, so >>>>>> that the file system gets large write requests even if the application >>>>>> works with a small block size? >>>> >>>> What is missing to make that possible? >>> >>> Not much, actually. One missing piece is allowing the fuse module to >>> cache mtime updates and flush them to the filesystem when the file is >>> synced or closed. > > Jiffies in the fuse file, added argument to the release/flush? > >> Oh, and there are issues with space reservation. Normally write >> reserves space or returns ENOSPC if there's no free space. But with >> fuse, for latency issues, we'd really need some sort of >> pre-reservation so that a request is not necessary for each write. > > That is more complicated for sure, and might not be worth it all of the time given the overhead of making that request to the file-system compared with just sending the write immediately (that would depend on the file-system and the maximum size of a write of course). > > On the other hand, the result could also be part of fsync/flush/release (if FUSE was updated to use the result of the release). I mean, is anything guaranteed with respect to free space if you aren't using O_DIRECT or O_SYNC until you fsync/flush/release? For my purposes I'd be comfortable with that limitation, although I can see it as a major difference with other file-systems. > > John. The choice could be simple: Let the user decide. If the user mounts with big writes enabled then writes will succeed and only later give an error on fsync/flush/release. If the user needs to know ENOSPC on writes directly then he can mount with small writes. Adding space reservation to fuse might be nice but not strictly neccessary before alowing big writes. MfG Goswin |