On Tue, Aug 18, 2026 at 5:51 PM Luis Henriques <[email protected]> wrote: > > On Tue, Aug 18 2026, Amir Goldstein wrote: > > > On Mon, Aug 17, 2026 at 4:11 PM Luis Henriques <[email protected]> wrote: > >> > >> This new file aims at documenting the caches that are used by FUSE. At > >> the moment only symlink, attributes, ACLs and readdir caches are described. > >> > >> Signed-off-by: Luis Henriques <[email protected]> > >> --- > >> .../filesystems/fuse/fuse-caches.rst | 142 ++++++++++++++++++ > >> 1 file changed, 142 insertions(+) > >> create mode 100644 Documentation/filesystems/fuse/fuse-caches.rst > >> > >> diff --git a/Documentation/filesystems/fuse/fuse-caches.rst > >> b/Documentation/filesystems/fuse/fuse-caches.rst > >> new file mode 100644 > >> index 000000000000..071febf45d00 > >> --- /dev/null > >> +++ b/Documentation/filesystems/fuse/fuse-caches.rst > >> @@ -0,0 +1,142 @@ > >> +.. SPDX-License-Identifier: GPL-2.0 > >> + > >> +=========== > >> +FUSE Caches > >> +=========== > >> + > >> +Introduction > >> +============ > >> + > >> +This document summarises the different types of caches that are used in > >> FUSE. > >> +For each cache type, it attempts to document the rules that are followed > >> to > >> +insert, validate and invalidate data into the cache. > >> + > >> +symlink caching > >> +=============== > >> + > >> +Whenever there's a link resolution request, the VFS will call into > >> +``fuse_get_link()`` which will then send a ``FUSE_READLINK`` request to > >> the > >> +user-space FUSE server. However, the server can ask the kernel to cache > >> all > >> +links resolutions by setting the ``FUSE_CACHE_SYMLINKS`` flag during the > >> +``FUSE_INIT`` negotiation. > >> + > >> +If this flag is set, FUSE will immediately call into the VFS > >> +``__page_get_link()`` from the ``->get_link()`` inode operation. The > >> first time > >> +this is done for a specific link, it will end-up sending the > >> ``FUSE_READLINK`` > >> +to user-space but the link contents will then be added into page-cache. > >> The next > >> +time the link needs to be resolved, it will use the link content that is > >> already > >> +cached, and will only fallback into sending the request to use-space if > >> the > >> +folio isn't up-to-date. > >> + > >> +Attributes caching > >> +================== > >> + > >> +Attributes obtained from user-space, for example when an inode is first > >> +looked-up, are cached in the kernel. However, these attributes have a > >> timeout > >> +associated and once expired they are invalidated. > >> + > >> +Thus, the ``FUSE_GETATTR`` operation will be sent to user-space only if > >> the > >> +attributes aren't yet available, the attributes aren't valid (timeout), > >> or if > >> +there is an explicit request for doing so (for example, by using the > >> +``AT_STATX_FORCE_SYNC`` flag in ``statx``). This may happen in the > >> following > >> +situations: > > > > "This may happen" what may happen? I don't see it referring to anything. > > Yeah, that sentence doesn't really make a lot of sense. I'll rephrase. > > >> + > >> +#. An explicit request from VFS to get the attributes for an inode > >> (through the > >> + ``->getattr()`` callback). > >> +#. When an ``->llseek()`` is requested to FUSE with a type of request > >> + (``whence``): > >> + > >> + - ``SEEK_{HOLE,DATA}`` and the user-space doesn't implement the > >> + ``FUSE_LSEEK`` operation (it has returned ``ENOSYS``), or > >> + - ``SEEK_END`` > >> + > >> +#. When doing a buffered read past EOF or automatic page cache > >> invalidation mode > >> + is enabled (``FUSE_AUTO_INVAL_DATA``). > >> +#. When doing a buffered write with write-back cache enabled > >> + (``FUSE_CAP_WRITEBACK_CACHE``). > > > > This list is incomplete and strange. it has post EOF write for > > writeback which is the exception > > and leaves out every non writeback write. > > This list was meant to list the scenarios where the FUSE_GETATTR is sent > (the "this may happen" above). But I'll review the list again. > > > If you composed this list yourself I highly recommend an LLM for this task > > if you used LLM I suggest a stronger model. > > > > Generally speaking, I find that today's robots are much better at writing > > these > > sorts of docs than I am - as long as I sit at the helm and guide them > > about where to expand on and where to keep it concise. > > Thank you for the suggestion (I did not use an LLM btw). In fact, do you > think this document is really useful, given that everyone will be running > an LLM anyway? (I've been asking this question myself...) >
LLM is very good in collecting information and arranging it in nicely formatted structures, but you need to keep a very good eye on the output and you need to focus on it to make the document relevant to the prospective audience of human readers. Running LLM to document without a human on the helm you can get half truths and plain lies. Also, for economic reasons, the way to work with LLM is to let it research the code base and create nice reviable "brain dumps" that you OR the LLM can read later into context. Doing this research every time is neither cost effective nor reliable nor deterministic. Thanks, Amir.
