From: M G, B. N. <bha...@hp...> - 2011-02-23 05:28:45
|
To make it a bit clear, I only show the user the file system cache, that I build from the index data (metadata) I read from my file system. Reading the data isn't the issue here, for me the issue is that when a read is issued, the data that needs to be fetched requires for me to get the source where the data resides and then fill the buffer. This overhead will kill the usability that I am hope to achieve with my use-case. Caching data shouldn't be an issue. The issue is to decide whether to fill the buffer with the cached data or get the full data from the source. This differentiation isn't available with fuse as it calls the same open() and read() functions be it preview or an actual read. But I will go through the links you have given below. Thanks, -Bharath From: Harshavardhana [mailto:ha...@gl...] Sent: Wednesday, February 23, 2011 9:58 AM To: M G, Bharath Narayan Cc: Lucas C. Villa Real; fus...@li... Subject: Re: [fuse-devel] Query on implementing `read' low level operation To simplify the problem do a read-ahead, read a larger page and cache it this way you will not hit performance issues with previews. The way done for pid is to look at /proc/ to provide us more details for eg: cmdline, snaps, stat . That we can ensure that its nautilus, this is ugly and never recommended if you want some serious FS implementation. There is no real problem with Nautilus in itself, in real world there are 100's of other applications which behave like Nautilus. It is the problem of reading being slow. Since the read call path could be blocking in your case waiting for the call to return back with data requested. The enhancements i am referring are based out for your code into non-blocking framework. Until you do that performance problems will bite you for ever. Please refer about the idea on readahead http://lwn.net/Articles/155510/ , this is internal kernel implementation. On the same ideas you should be implementing readahead in your code. Also ponder upon Non Blocking I/O and its implementation. Best place to start would be kegel's blog http://www.kegel.com/dkftpbench/nonblocking.html On Tue, Feb 22, 2011 at 8:05 PM, M G, Bharath Narayan <bha...@hp...<mailto:bha...@hp...>> wrote: That's something I could give a try. Also, I tried setting preview of text in icons to OFF and made changes in various other settings, but even then when the directory is opened, open() and then read() are called. Also, a thought on checking the pid, when open() and read are called by another application say Gedit (while viewing the file list in Nautilus) will the pid still be of Nautilus or that of Gedit? -- Bharath (Always Mobile) ----- Original message ----- > On Mon, Feb 21, 2011 at 5:51 AM, M G, Bharath Narayan > <bha...@hp...<mailto:bha...@hp...><mailto:bha...@hp...<mailto:bha...@hp...>>> wrote: > > Caching is possible, but for the preview as well a full read of a > file, the same read() is called from fuse. So I haven't currently > figured out a way to differentiate the two calls, and hence I started > the discussion thread. > > One option is to check the contents of fuse_get_context()->pid, and > check whether the process name under /proc/<pid>/ is "nautilus". It's > very likely that you will end up blocking some legitimate calls in > which you would want to have Nautilus read the file contents, though > -- not to mention that this is nothing but a hack. > > It would be best to patch Nautilus if it doesn't currently offer an > option to stop generating preview icons for a given volume instead. > > Cheers, > > -- > Lucas > "If you're looking for a reason I've a reason to give: pleasure, > little treasure" > ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ fuse-devel mailing list fus...@li...<mailto:fus...@li...> https://lists.sourceforge.net/lists/listinfo/fuse-devel -- Harshavardhana Gluster Inc - http://www.gluster.com<http://www.gluster.com/> +1(408)-770-1887, Ext-113 +1(916)-538-1466 |