From: Roman V S. <rv...@su...> - 2009-04-02 15:34:27
|
On Wed, 2009-04-01 at 23:18 -0700, Aditya Rajgarhia wrote: > Hi, > > In some previous messages, Miklos and others have said that data will be > cached twice if the fuse FS passes read operations to the native FS. I > am confused how this happens in terms of the implementation. I was > looking at the kernel code, and as far as I can see, in-memory pages for > a file are "owned' by that file's inode structure. Now, it seems to me > that when a file is opened by the fuse FS, the inode for that file would > get cached, and the native FS would then use that same, cached inode > which iget() will return. So each time the native FS reads a page from > disk, it would fill the page that was allocated for that inode by > do_sync_read() when it was called by fuse. i.e. fuse FS and native FS > should be using the same pages for a file. Is that not the case? Where > does the double caching occur? Just to be clear, I suppose that you are talking about the case where an application linked with FUSE library is doing I/O on the files coming from some other filesystem, correct? Let us also assume that fuse FS is mounted on /mnt/fuse and the application serving the request reads files from /mnt/other-fs Here's what happens after: read(open("/mnt/fuse/some-file.txt", O_RDONLY), &buf, 1); 0. because of the open there will be a dentry (and inode) allocated for /mnt/fuse/some-file.txt. We will call it inode#1. 1. when read gets invoked *and* the page cache doesn't have the page corresponding to inode#1 fuse will send the read message to the application. 2. application will get the read message and call read(open("/mnt/other-fs/some-file.txt", O_RDONLY), &buf, 1); 3. the kernel will go through the same motions, effectively allocating inode#2 corresponding to /mnt/other-fs/some-file.txt. 4. when read on inode#2 gets invoked the data gets fetched into a page cache corresponding to inode#2. the data will also be returned to an application. 5. that same data will be sent back to fuse and deposited into a page cache of inode #1. Thanks, Roman. |