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

From: Maxim Patlasov
Date: Wed Sep 11 2013 - 08:22:04 EST


On 09/11/2013 02:12 PM, Miklos Szeredi wrote:
On Fri, Aug 30, 2013 at 1:33 PM, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:
08/30/2013 01:13 PM, Miklos Szeredi ÐÐÑÐÑ:

On Thu, Aug 29, 2013 at 6:41 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
BTW, isn't it enough to do the filemap_write_and_wait() *plus* the
fuse_set_nowrite()?
Thought about it a bit and I think this should do fine.

Any writes before the fallocate will go trough before the fallocate.
i_mutex guarantees that only one instance of fuse_set_nowrite() is
running. Any mmaped writes during the fallocate() will go after the
fallocate request and the page cache truncation and that's fine too.
Page cache is consistent since it doens't contain pages for those
writes to the hole. Subsequent reads to that area will fill them in.

Any other concerns?

No. What you suggest looks as a neat and correct solution. I'll resend the
updated patch after some testing (since now till Monday).

As for proof-of-correctness, all you wrote above is correct, but the first
point had been boiling my mind for a while. I came to the following
reasoning (hopefully it is what you meant):

The fact that filemap_write_and_wait() returned infers that
end_page_writeback() was called for all relevant pages. And fuse doesn't
call it before adding request to fi->queued_writes and calling
fuse_flush_writepages(). And the latter, in turn, guarantees proper
accounting of request in fi->writectr. Here, of course, it's crucial that we
can't have concurrent fuse_set_nowrite(), as you explained. Hence, so far as
fi->writectr was bumped, fuse_set_nowrite() we call after
filemap_write_and_wait() would wait until all changes have gone to the
server.
Any news about this?

Testing updated patch revealed a problem (fsx caught data corruption). Then I instrumented debug version to get a cue. The debug version survived several days of testing, but now I discovered that that test setup was not fully correct. I'll re-run it now.

Thanks,
Maxim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/