Quantcast

Need clarification on the "kernel_cache" option

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need clarification on the "kernel_cache" option

Maruhan Park
I see in this link, http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html, that you can give a "kernel_cache" option that deals with caches on "open". I have couple questions regarding it.

1. The page says "This option disables flushing the cache of the file contents on every open(2)." When I read this, I inferred that when the option is not set, then the kernel would wipe the cache of file content on every open(2). 

However, I see the opposite below: "if  this  option is not specified (and neither direct_io) data is still cached after the open(2), so a read(2) system call will not always initiate a read operation."

Can I get a clarification on this?

2. When the page talks about "on every open(2)", is this talking about calling libc's open function? Is this unrelated to FUSE's open operation?

3. If the answer above is that it is talking about libc's open function, then how is libfuse isolating the cache actions to itself? To clarify, if FUSE's open operation just simply runs the libc's open function to a file located inside an ext3 filesystem, doesn't VFS call the open routine specific to ext3? This file isn't really under FUSE's jurisdiction isn't it?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need clarification on the "kernel_cache" option

Maruhan Park
Here's some additional information request on number 3. Just like the passthrough example as shown here, https://github.com/libfuse/libfuse/blob/master/example/passthrough.c, if we try to read "/mnt/fuse/file" but we are actually reading "/file", then is the following explanation correct?

1. Directory and inode information of "/mnt/fuse/file" gets cached in dcache and inode cache. (Not exactly sure how this can even be possible when I believe FUSE kernel does not have dentry and inode structure)
2. The file content and location of "/file" gets cached, and the inode and superblock of /mnt/fuse/file points to that cache.

So in essence, we have the following cached: 1. dentry/inode of /mnt/fuse/file, 2. dentry/inode of /file, 3. content data and location of /file

2017-01-03 10:30 GMT+09:00 박마루한 <[hidden email]>:
I see in this link, http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html, that you can give a "kernel_cache" option that deals with caches on "open". I have couple questions regarding it.

1. The page says "This option disables flushing the cache of the file contents on every open(2)." When I read this, I inferred that when the option is not set, then the kernel would wipe the cache of file content on every open(2). 

However, I see the opposite below: "if  this  option is not specified (and neither direct_io) data is still cached after the open(2), so a read(2) system call will not always initiate a read operation."

Can I get a clarification on this?

2. When the page talks about "on every open(2)", is this talking about calling libc's open function? Is this unrelated to FUSE's open operation?

3. If the answer above is that it is talking about libc's open function, then how is libfuse isolating the cache actions to itself? To clarify, if FUSE's open operation just simply runs the libc's open function to a file located inside an ext3 filesystem, doesn't VFS call the open routine specific to ext3? This file isn't really under FUSE's jurisdiction isn't it?


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...