[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] Fuse guarantees on concurrent requests
From:       Maxim Patlasov <mpatlasov () openvz ! org>
Date:       2015-04-01 21:45:43
Message-ID: 551C6707.9000202 () openvz ! org
[Download RAW message or body]

On 03/31/2015 08:35 PM, Aaron Jacobs wrote:
> On Wed, Apr 1, 2015 at 1:42 PM, Maxim Patlasov <mpatlasov@openvz.org> wrote:
>> Not exactly. fuse_flush firstly calls write_inode_now, then
>> fuse_sync_writes. The latter do wait for the write responses for all
>> writeback requests initiated by write_inode_now. That's the main point of
>> that "barrier": ensure that all dirty memory for given inode will hit
>> userspace daemon (and be ACK-ed by it) before sending FUSE_FLUSH. (you can
>> inspect the usage of fi->writectr to see how the waiting is implemented)
> I went and reverified the issue I was talking about, and I had gotten the
> details slightly wrong. Here's what the application code does (I can give you
> repro code if you'd like):
>
> 1. Create a file.
> 2. Write 4 bytes to the file.
> 3. mmap the file.
> 4. Modify the first byte of the file via the mapping.
> 5. munmap the file.
> 6. Close the file.
>
> The file system daemon sees the following sequence of requests:
>
> 1. Write 4 bytes (with the logical contents after the write in #2 above).
> 2. Read 4096 bytes.
> 3. Write 4 bytes (with the logical contents after the write in #4 above).
> 4. Flush.
>
> By adding sleeps, I can see that everything blocks on the response to the first
> write, but nothing blocks on the response to the second write.
>
> I suppose this is expected, since the user didn't use msync? So is the
> guarantee that fuse will wait on responses to all writes made through the file
> descriptor (but not necessarily the memory mapping) before sending the flush?

No. That's true only w.r.t writeback writes (i.e. memory mapping and 
buffered writes if FUSE_WRITEBACK_CACHE is enabled).


>> As for the other questions, the rule of thumb (imho) is that kernel fuse
>> serializes requests only if the lack of it would lead to user data
>> corruption. If the serialization can be done on the side of userspace
>> daemon, kernel fuse won't serialize.
> This sort of rule of thumb is what I'm looking for, but I don't quite
> understand it. Could you elaborate a bit? What kind of serialization "can be
> done on the side of the userspace daemon", for example?

The fact that userspace daemon managed to read several requests from 
/dev/fuse in a row already implies that kernel fuse doesn't expect any 
specific order of processing them. Hence, there are no reasons for 
userspace to serialize them.

But if you get REQ1 from /dev/fuse, process and ACK it, then get REQ2, 
process and ACK it, of course, you must serialize your processing of 
REQ1 and REQ2 on the side of userspace daemon.

>
> Also, are you able to give the yes/no answers to questions #3 and #4 in my
> original email (about write->read barriers and setattr->getattr barriers)? It
> would help a newbie out a lot. :-)

AFAIU, kernel fuse never sends next request before getting ACK for 
previous one if user expects corresponding operations to be ordered.

Thanks,
Maxim

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]