From: 松涛 林 <son...@ho...> - 2011-09-20 12:39:54
|
Hi, all If read() work on fuse, does the kernel page cache keep the read content in memory and return in next read()? Best Regards SongTao Lin |
From: Han-Wen N. <ha...@gm...> - 2011-09-20 13:01:23
|
Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. On Tue, Sep 20, 2011 at 9:39 AM, 松涛 林 <son...@ho...> wrote: > Hi, all > If read() work on fuse, does the kernel page cache keep the read content in memory and return in next read()? > -- Han-Wen Nienhuys - ha...@xs... - http://www.xs4all.nl/~hanwen |
From: Sven U. <sve...@gm...> - 2011-09-20 16:00:31
|
Hello Han-Wen, > > If read() work on fuse, does the kernel page cache keep the read > > content in memory and return in next read()? > Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. Why would that be necessary? Or, put another way round, how can I influence that from my FUSE-using program? Obviously I can not rely on some other program to open anything with FOPEN_KEEP_CACHE --- or am I misreading you? Sven -- _ ___ ___ ___ The dCache File System __| |/ __|| __|/ __| An archive file-system for PB of data / _` | (__ | _| \__ \ http://www.desy.de/~utcke/Data/ \__,_|\___||_| |___/ http://www.dr-utcke.de/ |
From: Lucas C. V. R. <lu...@go...> - 2011-09-20 19:23:40
|
On Tue, Sep 20, 2011 at 1:00 PM, Sven Utcke <sve...@gm...> wrote: > Hello Han-Wen, > >> > If read() work on fuse, does the kernel page cache keep the read >> > content in memory and return in next read()? > >> Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. > > Why would that be necessary? Or, put another way round, how can I > influence that from my FUSE-using program? Obviously I can not rely > on some other program to open anything with FOPEN_KEEP_CACHE --- or am > I misreading you? Hi Sven, The flag that Han-Wen mentioned is to be set from the FUSE file system's open() operation, not from the client side. The struct fuse_file_info, filled in by open(), has a member named "keep_cache" which can be set to '1' to tell the kernel that the cached file data doesn't need to be invalidated. Thanks, -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure" |
From: Sven U. <sve...@gm...> - 2011-09-20 20:18:23
|
Hello Lucas, > >> Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. > The flag that Han-Wen mentioned is to be set from the FUSE file > system's open() operation, not from the client side. The struct > fuse_file_info, filled in by open(), has a member named "keep_cache" > which can be set to '1' to tell the kernel that the cached file data > doesn't need to be invalidated. I see. Is there any documentation on this (and all the other) flags? So, assuming I have a write-through filesystem, say, I could simply always set this flag without ill effects? Sven -- _ ___ ___ ___ The dCache File System __| |/ __|| __|/ __| An archive file-system for PB of data / _` | (__ | _| \__ \ http://www.desy.de/~utcke/Data/ \__,_|\___||_| |___/ http://www.dr-utcke.de/ |
From: Goswin v. B. <gos...@we...> - 2011-09-28 13:37:31
|
Sven Utcke <sve...@gm...> writes: > Hello Lucas, > >> >> Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. > >> The flag that Han-Wen mentioned is to be set from the FUSE file >> system's open() operation, not from the client side. The struct >> fuse_file_info, filled in by open(), has a member named "keep_cache" >> which can be set to '1' to tell the kernel that the cached file data >> doesn't need to be invalidated. > > I see. Is there any documentation on this (and all the other) flags? > > So, assuming I have a write-through filesystem, say, I could simply > always set this flag without ill effects? > > Sven If anything writes to the underlying filesystem other than fuse then you will get cache coherency issues. The data that is on disk might not match the data in cache. I would think it is only safe to set this if you don't have a write-through filesystem. MfG Goswin |
From: Lucas C. V. R. <lu...@go...> - 2011-09-20 21:56:34
|
On Tue, Sep 20, 2011 at 5:18 PM, Sven Utcke <sve...@gm...> wrote: > Hello Lucas, > >> >> Yes if you pass the FOPEN_KEEP_CACHE flag from the open() method. > >> The flag that Han-Wen mentioned is to be set from the FUSE file >> system's open() operation, not from the client side. The struct >> fuse_file_info, filled in by open(), has a member named "keep_cache" >> which can be set to '1' to tell the kernel that the cached file data >> doesn't need to be invalidated. > > I see. Is there any documentation on this (and all the other) flags? I don't think there is any. The header files are well documented, though. This particular flag (along with a set of other ones) is described on fuse_common.h, in the declaration of struct fuse_file_info. > So, assuming I have a write-through filesystem, say, I could simply > always set this flag without ill effects? Having never used that flag myself I cannot say much. Let's see if someone who experienced using that flag can answer that. Han-Wen? -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure" |
From: Han-Wen N. <ha...@gm...> - 2011-09-21 01:22:35
|
On Tue, Sep 20, 2011 at 6:56 PM, Lucas C. Villa Real <lu...@go...> wrote: >> So, assuming I have a write-through filesystem, say, I could simply >> always set this flag without ill effects? > > Having never used that flag myself I cannot say much. Let's see if > someone who experienced using that flag can answer that. Han-Wen? If your FS is exposing something that may change through external means (for example: sshfs, where the remote host may change the files), you should probably not set it, but if you are in control of all data changes, it should be ok. If you know when data changes, you can use inode notify to make sure the kernel invalidates its caches. -- Han-Wen Nienhuys - ha...@xs... - http://www.xs4all.nl/~hanwen |
From: John M. <jo...@jm...> - 2011-09-21 08:21:51
|
On 2011.09.21, at 3:22 , Han-Wen Nienhuys wrote: > On Tue, Sep 20, 2011 at 6:56 PM, Lucas C. Villa Real > <lu...@go...> wrote: > >>> So, assuming I have a write-through filesystem, say, I could simply >>> always set this flag without ill effects? >> >> Having never used that flag myself I cannot say much. Let's see if >> someone who experienced using that flag can answer that. Han-Wen? > > If your FS is exposing something that may change through external > means (for example: sshfs, where the remote host may change the > files), you should probably not set it, but if you are in control of > all data changes, it should be ok. If you know when data changes, you > can use inode notify to make sure the kernel invalidates its caches. My file-system sets 'struct fuse_file_info -> keep_cache' to 1 for every file. When changes are made by a remote host, the local kernel is notified with 'fuse_lowlevel_notify_inval_inode()'. This function allows you to specify that parts of the cache are no longer valid. Subsequent reads of the file result in read operations to your fuse file-system process. I believe that you can also use 'fuse_lowlevel_notify_store()' to store data written by a remote node. In the case of my file-system, use of this function 'synchronously' would result in dead-lock with a local process that tries to modify the file at the same time as a remote process. Asynchronous use is impossible since then there is a race condition between local and remote changes. If on the other hand, you only allow reads from the local system while the remote system can make changes, then 'fuse_lowlevel_notify_store()' might work for you. Cheers, John. |
From: Miklos S. <mi...@sz...> - 2011-09-21 12:32:02
|
John Muir <jo...@jm...> writes: > When changes are made by a remote host, the local kernel is notified > with 'fuse_lowlevel_notify_inval_inode()'. This function allows you to > specify that parts of the cache are no longer valid. Subsequent reads > of the file result in read operations to your fuse file-system > process. > > I believe that you can also use 'fuse_lowlevel_notify_store()' to > store data written by a remote node. In the case of my file-system, > use of this function 'synchronously' would result in dead-lock with a > local process that tries to modify the file at the same time as a > remote process. I haven't tried this, but... The kernel itself uses locking on the pages to prevent concurrent writes to the same page. But that in itself shouldn't cause a deadlock. If your filesystem uses locking in ->write() and around fuse_lowlevel_notify_store() then yes, that would deadlock. But is that necessary? Am I missing something? Thanks, Miklos |
From: John M. <jo...@jm...> - 2011-09-21 12:59:48
|
On 2011.09.21, at 14:31 , Miklos Szeredi wrote: >> I believe that you can also use 'fuse_lowlevel_notify_store()' to >> store data written by a remote node. In the case of my file-system, >> use of this function 'synchronously' would result in dead-lock with a >> local process that tries to modify the file at the same time as a >> remote process. > > The kernel itself uses locking on the pages to prevent concurrent writes > to the same page. But that in itself shouldn't cause a deadlock. > > If your filesystem uses locking in ->write() and around > fuse_lowlevel_notify_store() then yes, that would deadlock. But is that > necessary? > > Am I missing something? Yes. My simplified explanation doesn't give all of the details. The dead-lock is not within the kernel, but within my file-system. When a remote writer writes to the file-system, it acquires a (write) lock on that inode within the file-system. If a local process also writes to the same inode via the kernel, it first acquires the kernel's lock, and then within the file-system attempts to lock within the file-system. If the remote writer was then to attempt to synchronously fuse_lowlevel_notify_store(), then it would lock within the kernel, and so both the remote thread and local thread would be locked waiting. Note that the same problem exists with the 'notify_inval_inode()', but in that case the notification is done via a separate thread to avoid the above dead-lock, and since notify_inval_inode() does not actually change the contents of the file, it can be executed asynchronously. At the end of the day, the locking within the file-system is required in order to guarantee that the file-system contents are the same on both nodes. John. |