[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