Re: [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate()

From: Maxim Patlasov
Date: Tue Aug 13 2013 - 09:45:42 EST

08/13/2013 05:23 PM, Brian Foster ÐÐÑÐÑ:
On 08/13/2013 08:56 AM, Maxim Patlasov wrote:

08/13/2013 04:05 PM, Brian Foster ÐÐÑÐÑ:
@@ -2478,8 +2516,11 @@ static long fuse_file_fallocate(struct file
*file, int mode, loff_t offset,
if (lock_inode) {
- if (mode & FALLOC_FL_PUNCH_HOLE)
- fuse_set_nowrite(inode);
+ if (mode & FALLOC_FL_PUNCH_HOLE) {
+ truncate_pagecache_range(inode, offset,
+ offset + length - 1);
+ fuse_wait_on_writeback(inode, offset, length);
+ }
If this happens to be the first attempt on an fs that doesn't support
fallocate, we'll return -EOPNOTSUPP after having already punched out the
data in the pagecache.
Yes, this is unpleasant, but it's not critical, imo. We're returning an
error code (even though equal to -EOPNOTSUPP) and a sane application
should not make any assumption about current state of the punched
region. Also, the application intended to discard given region of the
file, so why should it pay care for its content afterwards?

I agree, though most users probably wouldn't expect that a blatant error
like EOPNOTSUPP leave the range in a weird state. What's more, it only
does so if it's the first attempt and behaves more appropriately after

What about replacing the nowrite logic with a
flush (and still followed by your new writeback wait logic) rather than
moving the pagecache truncate?
The "flush" you mentioned should firstly flush page cache.
invalidate_inode_pages2_range() seems to be a candidate. We definitely
cannot ignore error code from it because it can be fuse_launder_page()
who got -ENOMEM from fuse_writepage_locked(). In case of err == -ENOMEM,
we could safely fail fallocate, but what should we do if it's -EBUSY?
Any ideas?

I was referring to something like filemap_write_and_wait_range(), for
example. Then continue to use truncate_pagecache_range() as we do today.

Looks nice. I'll send updated patch after some testing. Thanks a lot for the suggestion!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at