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

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Aug 2 06:41:16 UTC 2018


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

Jakub Kruszona-Zawadzki <acid at moosefs.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acid at moosefs.com

--- Comment #4 from Jakub Kruszona-Zawadzki <acid at moosefs.com> ---
I've checked it using "DIRECT" flag - result is almost the same:

hello1:
t1
t3
t5
t6

hello2:
t1
t3
t5
t6

Still no 't2' and no 't4'. Our problem is not in data caching - this can be
fixed using 'direct_io' (not vary good solution, but it works). The problem is
connected with dentry cache - i.e. file length. Because of this cache operation
"echo 't3' >> /mnt/llfuse/hello1" uses old file length and overwrites 't2'.

In Linux and OS X this works fine. On FreeBSD it looks like 'timeout' parameter
returned with attributes (getattr) and entry data (lookup) is totally ignored.

For example - output from OS X (original version - without direct):


hello1:
t1
t2
t3
t4
t5

hello2:
t1
t2
t3
t4
t5
t6


Still no 't6' in 'hello1' - probably they had similar issue and 'fixed' this by
invoking 'getattr' whenever file is opened with O_APPEND, so data are appended
properly, but then when 'hello1' is read without 'O_APPEND' it also uses "old"
file length.

On Linux there is 't6' in 'hello1' (proper timeouting attributes).


As for now there is no work-around for this issue. We've mentioned
'fuse_lowlevel_notify_inval_entry' only because it could be used as a
work-around. We do not use this function in our current implementation.

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


More information about the freebsd-bugs mailing list