From: Franco B. <fr...@ro...> - 2004-07-28 02:52:27
|
Hi Miklos I was looking at your cute little "hello world" example and thought I could use this technique to get some diagnostics from my filesystem. I got something simple to work but soon discovered that the contents of the special file weren't changing. I traced this back to the caching - the read routine was not being called after the initial access. Any idea what I can do the refresh the contents? I guess the system has no way of knowing that the page read from the file has changed. Thanks Franco |
From: Miklos S. <mi...@sz...> - 2004-07-28 07:51:05
|
> I was looking at your cute little "hello world" example and thought I > could use this technique to get some diagnostics from my filesystem. > > I got something simple to work but soon discovered that the contents of > the special file weren't changing. I traced this back to the caching - > the read routine was not being called after the initial access. > > Any idea what I can do the refresh the contents? I guess the system has > no way of knowing that the page read from the file has changed. Yes, that's one area, where there's a need for some improvement. It would be possible to check the file modification time and size in each read after some timeout (e.g 1 sec) and refresh the contents if they changed. There is also a filesystem initiated call INVALIDATE, which is currently not exported to the library, but that could easily be done. This may not be the best interface for you though, because for this your program needs to generate an asynchronous event each time the file contents changed. Which solution would be better for Which would be better for you? Miklos |
From: Franco B. <fr...@ro...> - 2004-07-28 08:07:33
|
On Wed, 2004-07-28 at 15:49, Miklos Szeredi wrote: > > I was looking at your cute little "hello world" example and thought I > > could use this technique to get some diagnostics from my filesystem. > > > > I got something simple to work but soon discovered that the contents of > > the special file weren't changing. I traced this back to the caching - > > the read routine was not being called after the initial access. > > > > Any idea what I can do the refresh the contents? I guess the system has > > no way of knowing that the page read from the file has changed. > > Yes, that's one area, where there's a need for some improvement. It > would be possible to check the file modification time and size in each > read after some timeout (e.g 1 sec) and refresh the contents if they > changed. > > There is also a filesystem initiated call INVALIDATE, which is > currently not exported to the library, but that could easily be done. > This may not be the best interface for you though, because for this > your program needs to generate an asynchronous event each time the > file contents changed. Which solution would be better for > > Which would be better for you? The second option sounds like it makes more sense to me if I can call INVALIDATE before returning from the read operation. Would that work? > > Miklos > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Avf-fuse-dev mailing list > Avf...@li... > https://lists.sourceforge.net/lists/listinfo/avf-fuse-dev |
From: Miklos S. <mi...@sz...> - 2004-07-28 11:30:14
|
> The second option sounds like it makes more sense to me if I can call > INVALIDATE before returning from the read operation. Would that work? No, because that will only invalidate things already in the cache. Actually I forgot the third option: direct reads (-o direct_io). With this mount option files are never cached. But this is a filesystem wide option, and currently mmap()-ing doesn't work if direct_io is turned on. Miklos |
From: Franco B. <fr...@cl...> - 2004-07-28 11:55:37
|
On Wed, 2004-07-28 at 19:28, Miklos Szeredi wrote: > > The second option sounds like it makes more sense to me if I can call > > INVALIDATE before returning from the read operation. Would that work? > > No, because that will only invalidate things already in the cache. > Actually I forgot the third option: direct reads (-o direct_io). With > this mount option files are never cached. But this is a filesystem > wide option, and currently mmap()-ing doesn't work if direct_io is > turned on. It's only when someone reads the special file that I gather the diagnostic information to return in the read buffer, so I guess I can call INVALIDATE during the open or even the release - does it use the path as an argument? |
From: Miklos S. <mi...@sz...> - 2004-07-28 14:47:25
|
> It's only when someone reads the special file that I gather the > diagnostic information to return in the read buffer, so I guess I can > call INVALIDATE during the open or even the release - does it use the > path as an argument? Cached pages are automatically invalidated in open(), so there's no need to do this. This is why this problem in not so grave: it's rare that some program keeps a file open for long periods, during which the file can change. The INVALIDATE method has really been created for use with the 'kernel_cache' (or -c) mount option, which otherwise disables cache invalidation in open. Miklos |