Re: [PATCH] GOP_ALLOC and fallocate for PUFFS

[Antti Kantee <pooka%cs.hut.fi@localhost>]

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.