Summary: | [FUSEFS] Inode attributes are cached unnecessarily/for too long | ||
---|---|---|---|
Product: | Base System | Reporter: | Agata <chogata> |
Component: | kern | Assignee: | Alan Somers <asomers> |
Status: | Closed FIXED | ||
Severity: | Affects Some People | CC: | asomers, freebsd, jSML4ThWwBID69YC, piotr.konopelko |
Priority: | --- | Flags: | asomers:
mfc-stable13+
asomers: mfc-stable12+ |
Version: | 13.0-RELEASE | ||
Hardware: | Any | ||
OS: | Any | ||
URL: | https://reviews.freebsd.org/D33283 |
Description
Agata
2021-08-24 11:30:38 UTC
I'll look into this when I have some time. But could you please tell me what FUSE protocol version MooseFS is mounting with? Earlier protocol versions had very limited ability to specify cache retention times. This is directly from the test machine I did this particular test on: compiled_with_fuse: 3.2 kernel_fuse_protocol: 7.28 I don't know about our users, but I assume they mount with the latest they get with the system. As a user, here's my settings. compiled_with_fuse: 31.0 kernel_fuse_protocol: 7.28 PKG: fusefs-libs3-3.10.4 PKG: moosefs3-client-3.0.116 Patch in review. Note that this bug actually didn't have anything to do with inode attributes. The file type isn't considered an attribute, because it must remain the same throughout a file's lifetime. So the entry cache is more relevant than the attribute cache. But as it turns out, the best way to handle this situation is the same regardless of whether the entry cache has expired or not. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=25927e068fcbcac0a5111a881de723bd984b04b3 commit 25927e068fcbcac0a5111a881de723bd984b04b3 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2021-12-06 05:43:17 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2021-12-07 04:36:46 +0000 fusefs: correctly handle an inode that changes file types Correctly handle the situation where a FUSE server unlinks a file, then creates a new file of a different type but with the same inode number. Previously fuse_vnop_lookup in this situation would return EAGAIN. But since it didn't call vgone(), the vnode couldn't be reused right away. Fix this by immediately calling vgone() and reallocating a new vnode. This problem can occur in three code paths, during VOP_LOOKUP, VOP_SETATTR, or following FUSE_GETATTR, which usually happens during VOP_GETATTR but can occur during other vops, too. Note that the correct response actually doesn't depend on whether the entry cache has expired. In fact, during VOP_LOOKUP, we can't even tell. Either it has expired already, or else the vnode got reclaimed by vnlru. Also, correct the error code during the VOP_SETATTR path. PR: 258022 Reported by: chogata@moosefs.pro MFC after: 2 weeks Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33283 sys/fs/fuse/fuse_internal.c | 9 +++++--- sys/fs/fuse/fuse_node.c | 25 +++++++++++---------- tests/sys/fs/fusefs/getattr.cc | 50 ++++++++++++++++++++++++++++++++++++++++++ tests/sys/fs/fusefs/lookup.cc | 32 +++++++++++++++++++++------ tests/sys/fs/fusefs/setattr.cc | 47 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 142 insertions(+), 21 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=139764c4613cde14c97ff8dd8007eb0f27f5fb9f commit 139764c4613cde14c97ff8dd8007eb0f27f5fb9f Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2021-12-06 05:43:17 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-01-03 02:36:38 +0000 fusefs: correctly handle an inode that changes file types Correctly handle the situation where a FUSE server unlinks a file, then creates a new file of a different type but with the same inode number. Previously fuse_vnop_lookup in this situation would return EAGAIN. But since it didn't call vgone(), the vnode couldn't be reused right away. Fix this by immediately calling vgone() and reallocating a new vnode. This problem can occur in three code paths, during VOP_LOOKUP, VOP_SETATTR, or following FUSE_GETATTR, which usually happens during VOP_GETATTR but can occur during other vops, too. Note that the correct response actually doesn't depend on whether the entry cache has expired. In fact, during VOP_LOOKUP, we can't even tell. Either it has expired already, or else the vnode got reclaimed by vnlru. Also, correct the error code during the VOP_SETATTR path. PR: 258022 Reported by: chogata@moosefs.pro Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33283 (cherry picked from commit 25927e068fcbcac0a5111a881de723bd984b04b3) sys/fs/fuse/fuse_internal.c | 9 +++++--- sys/fs/fuse/fuse_node.c | 25 +++++++++++---------- tests/sys/fs/fusefs/getattr.cc | 50 ++++++++++++++++++++++++++++++++++++++++++ tests/sys/fs/fusefs/lookup.cc | 32 +++++++++++++++++++++------ tests/sys/fs/fusefs/setattr.cc | 47 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 142 insertions(+), 21 deletions(-) A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f09df4b05cf4b9f065e3db642666355a95c036e4 commit f09df4b05cf4b9f065e3db642666355a95c036e4 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2021-12-06 05:43:17 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-01-03 05:15:38 +0000 fusefs: correctly handle an inode that changes file types Correctly handle the situation where a FUSE server unlinks a file, then creates a new file of a different type but with the same inode number. Previously fuse_vnop_lookup in this situation would return EAGAIN. But since it didn't call vgone(), the vnode couldn't be reused right away. Fix this by immediately calling vgone() and reallocating a new vnode. This problem can occur in three code paths, during VOP_LOOKUP, VOP_SETATTR, or following FUSE_GETATTR, which usually happens during VOP_GETATTR but can occur during other vops, too. Note that the correct response actually doesn't depend on whether the entry cache has expired. In fact, during VOP_LOOKUP, we can't even tell. Either it has expired already, or else the vnode got reclaimed by vnlru. Also, correct the error code during the VOP_SETATTR path. PR: 258022 Reported by: chogata@moosefs.pro Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D33283 (cherry picked from commit 25927e068fcbcac0a5111a881de723bd984b04b3) sys/fs/fuse/fuse_internal.c | 9 +++++--- sys/fs/fuse/fuse_node.c | 25 +++++++++++---------- tests/sys/fs/fusefs/getattr.cc | 50 ++++++++++++++++++++++++++++++++++++++++++ tests/sys/fs/fusefs/lookup.cc | 32 +++++++++++++++++++++------ tests/sys/fs/fusefs/setattr.cc | 47 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 142 insertions(+), 21 deletions(-) |