On 30/09/14 13:44, Emmanuel Dreyfus wrote:
Hello
When a PUFFS filesystem uses the page cache, data enters the
cache with no guarantee it will be flushed. If it cannot be flushed
(bcause PUFFS write requests get EDQUOT or ENOSPC), then the
kernel will loop forever trying to flush data from the cache,
and the filesystem cannot be unmounted without -f (and data loss).
In the attached patch, I add in PUFFS:
- support for the fallocate operation
- a puffs_gop_alloe() function that use fallocate
- when writing through the page cache we call first GOP_ALLOC to make
sure backend storage is allocated for the data we cache. debug printf
show a sane behavior, GOP_ALLOC calling puffs_gop_alloc only when required.
If the filesystem does not implement fallocate, we keep the current
behavior of filling the page cache with data we are not sure we can flush.
Perhaps we can improve further: missing fallocate can be emulated by
writing zeroed chuncks. I have implemented that in libperfuse, but
we may want to have this in libpuffs, enabled by a mount option. Input
welcome.
Is it really better to sync fallocate, put stuff in the page cache and
flush the page cache some day instead of just having a write-through (or
write-first) page cache on the write() path? You also get rid of the
fallocate-not-implemented problem that way.
That still leaves the mmap path ... but mmap always causes annoying
problems and should just die ;)
Writing zeroes might be a bad emulation for distributed file systems,
though I guess you're the expert in that field and can evaluate the
risks better than me.
