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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
