[Bug 230258] [FUSE] [BUG]: Attributes caching issue

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Aug 1 12:35:40 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230258

            Bug ID: 230258
           Summary: [FUSE] [BUG]: Attributes caching issue
           Product: Base System
           Version: 11.1-RELEASE
          Hardware: Any
               URL: https://robo.moosefs.com/support/fuse_helloworld.tgz
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: freebsd at moosefs.com

This is one of three issues we detected in FreeBSD FUSE while developing our
distributed file system. All four issues can be replicated using this simple
test script:
https://robo.moosefs.com/support/fuse_helloworld.tgz

FreeBSD FUSE is keeping attributes it should not keep. Example: when kernel
invokes lookup, one can say how long the result is kept in cache. We return 0
(0.0) timeout, but we still get results that suggest file length is kept in
cache.

What happens: we have two clients using our distributed file system. Each
client has access to the same file. For convienience sake, let's say those
files are named /mnt/llfuse/hello1 on client one and /mnt/llfuse/hello2 on
client two. But both files point to the SAME OBJECT in the filesystem.
When client one reads /mnt/llfuse/hello1, a minute later client two writes
something to /mnt/llfuse/hello2, and yet a minute later client one reads
/mnt/llfuse/hello1, client one does NOT see the data appended by client two.

After we perform this set of operations:

truncate -s 0 /mnt/llfuse/hello1
truncate -s 0 /mnt/llfuse/hello2
sleep 0.1
echo "t1" >> /mnt/llfuse/hello1
sleep 0.1
echo "t2" >> /mnt/llfuse/hello2
sleep 0.1
echo "t3" >> /mnt/llfuse/hello1
sleep 0.1
echo "t4" >> /mnt/llfuse/hello2
sleep 0.1
echo "t5" >> /mnt/llfuse/hello1
sleep 0.1
echo "t6" >> /mnt/llfuse/hello2
sleep 0.1

We get in result:

cat /mnt/llfuse/hello1
t1
t3
t5

cat /mnt/llfuse/hello2
t1
t3
t5
t6

Which is, of course, not the correct content of the file we just wrote to.

We tried also to use fuse_lowlevel_notify_inval_entry function to get rid of
the problem, but it returns EINVAL and writes "fuse: writing device: Invalid
argument" to screen.

Best regards,
Peter / MooseFS Team

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list