Date: Wed, 01 Aug 2018 12:35:36 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230258] [FUSE] [BUG]: Attributes caching issue Message-ID: <bug-230258-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230258 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@FreeBSD.org Reporter: freebsd@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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230258-227>