Re: [fuse-devel] Fuse guarantees on concurrent requests

[Aaron J. <ja...@go...>]

On Wed, Apr 1, 2015 at 1:42 PM, Maxim Patlasov <mpa...@op...> 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?


> 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?

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. :-)

Thanks,
Aaron