On Fri, Aug 30, 2013 at 1:33 PM, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote:08/30/2013 01:13 PM, Miklos Szeredi ÐÐÑÐÑ:Any news about this?
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* theThought about it a bit and I think this should do fine.
fuse_set_nowrite()?
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.