Date: Thu, 02 Aug 2018 06:41:14 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230258] [FUSE] [BUG]: Attributes caching issue Message-ID: <bug-230258-227-0c75RsiqQr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230258-227@https.bugs.freebsd.org/bugzilla/> References: <bug-230258-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230258 Jakub Kruszona-Zawadzki <acid@moosefs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acid@moosefs.com --- Comment #4 from Jakub Kruszona-Zawadzki <acid@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 opera= tion "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' param= eter returned with attributes (getattr) and entry data (lookup) is totally ignor= ed. 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' thi= s by invoking 'getattr' whenever file is opened with O_APPEND, so data are appen= ded properly, but then when 'hello1' is read without 'O_APPEND' it also uses "o= ld" 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. --=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-0c75RsiqQr>