From: Maxim Patlasov <mpatlasov@parallels.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: fuse-devel <fuse-devel@lists.sourceforge.net>,
Brian Foster <bfoster@redhat.com>,
Pavel Emelianov <xemul@parallels.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
<devel@openvz.org>
Subject: Re: [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate() -v2
Date: Fri, 30 Aug 2013 15:33:39 +0400 [thread overview]
Message-ID: <52208313.6000700@parallels.com> (raw)
In-Reply-To: <CAJfpegueaj7dF1SL68=pKSTO-q6RnbD-D=C65B8RGEPC4_DMfQ@mail.gmail.com>
08/30/2013 01:13 PM, Miklos Szeredi пишет:
> On Thu, Aug 29, 2013 at 6:41 PM, Miklos Szeredi <miklos@szeredi.hu> 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.
Thanks,
Maxim
next prev parent reply other threads:[~2013-08-30 11:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 16:39 [PATCH 0/2] fuse: fix races related to fuse writeback Maxim Patlasov
2013-08-12 16:39 ` [PATCH 1/2] fuse: postpone end_page_writeback() in fuse_writepage_locked() Maxim Patlasov
2013-08-29 16:27 ` Miklos Szeredi
2013-08-12 16:39 ` [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate() Maxim Patlasov
2013-08-13 12:05 ` Brian Foster
2013-08-13 12:56 ` Maxim Patlasov
2013-08-13 13:23 ` Brian Foster
2013-08-13 13:45 ` Maxim Patlasov
2013-08-16 11:30 ` [PATCH 2/2] fuse: wait for writeback in fuse_file_fallocate() -v2 Maxim Patlasov
2013-08-23 13:02 ` Brian Foster
2013-08-29 15:41 ` Miklos Szeredi
2013-08-29 16:27 ` Maxim Patlasov
2013-08-29 16:37 ` Miklos Szeredi
2013-08-29 16:41 ` Miklos Szeredi
2013-08-30 9:13 ` Miklos Szeredi
2013-08-30 11:33 ` Maxim Patlasov [this message]
2013-09-11 10:12 ` Miklos Szeredi
2013-09-11 12:21 ` Maxim Patlasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52208313.6000700@parallels.com \
--to=mpatlasov@parallels.com \
--cc=bfoster@redhat.com \
--cc=devel@openvz.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.