Bernhard, Good to hear that its working well for you. It would be nice to know how timeout + io-cache combination works for you. Also, in the future versions, we plan to enhance io-cache further, in a way that, if a file content is completely cached, then even open/close will be handled purely on client side, effectively improving the overall open()/stat()/read()/close() cycle turnaround time significantly. I believe this will help web servers serving images and static pages a long way. thanks, avati 2007/8/10, Bernhard J. M. Grün <bernhard.gruen@xxxxxxxxxxxxxx>: > > Anand, > > Thank you again for your great work. It seems that the timeouts are > working correctly. At the moment we are using one of our client > machines without io-cache but with 3600 second timeouts and another > client machine with io-cache (1024MB, 64KB page size) but without any > other modifications. This works in our setup because we don't delete > or modify files on our storage. It seems that the machine with the > changed timeouts is nearly as fast as the machine with io-cache > enabled. We'll test some other configurations and other values for > io-thread, io-cache and timeouts in the next few days. > All in all it seems that this new version of glusterfs runs stable in our > setup. > Therefore a big THANK YOU to you and all of your colleagues. You are > doing great work! > > Bernhard J. M. Grün > > 2007/8/8, Anand Avati <avati@xxxxxxxxxxxxx>: > > Bernhard, > > Can you checkout the latest repository snapshot and re-run your tests, > > except this time mounting glusterfs with '--entry-timeout 10.0 > > --attr-timeout 10.0' which sets and entry and attribute timeouts of 10 > > seconds for every file. > > > > avati > > > > 2007/8/8, Anand Avati <avati@xxxxxxxxxxxxx>: > > > Bernhard, > > > In fuse based filesystems, the filesystem can set the stat cache > timeout > > value. By default it is 1 second. On disk based filesystems this timeout > is > > 'infinite' (till the dentry cache is shrunk, stat() never goes to the > disk > > for a second time). But for network based filesystems it is unsafe to > set > > such high stat cache timeouts. Still you are free to try. Currently in > the > > GlusterFS codebase this value is hardcoded to 1 sec. I'll be adding a > > command line argument to set this timeout for you to experiment with it. > > Please let us know your results. > > > > > > thanks, > > > avati > > > > > > > > > 2007/8/6, Bernhard J. M. Grün <bernhard.gruen@xxxxxxxxxxxxxx >: > > > > > > > Hello developers! > > > > > > > > At the moment we try to optimize our web server setup again. > > > > We tried to parallelize the stat calls in our web server software > > > > (lighttpd). But it seems the kernel does not cache the stat > > > > information from one request for further requests. But the same > setup > > > > works fine on a local file system. So it seems that glusterFS and/or > > > > FUSE is not able to communicate with the kernel (stat) cache. Is > this > > > > right? And is this problem solvable? > > > > > > > > Here is some schematic diagram of our approach: > > > > request -> lighttpd -> Threaded FastCGI program, that does only a > stat > > > > (via fopen) -> lighttpd opens the file for reading and writes the > date > > > > to the socket > > > > > > > > > > > > In a local scenario the second open uses the cached stat and so it > > > > does not block other reads in lighty at that point. but with a > > > > glusterFS mount it still blocks there. > > > > > > > > Maybe you can give me some advice. Thank you! > > > > > > > > Bernhard J. M. Grün > > > > > > > > > > > > _______________________________________________ > > > > Gluster-devel mailing list > > > > Gluster-devel@xxxxxxxxxx > > > > http://lists.nongnu.org/mailman/listinfo/gluster-devel > > > > > > > > > > > > > > > > -- > > > It always takes longer than you expect, even when you take into > account > > Hofstadter's Law. > > > > > > -- Hofstadter's Law > > > > > > > > -- > > It always takes longer than you expect, even when you take into account > > Hofstadter's Law. > > > > -- Hofstadter's Law > -- It always takes longer than you expect, even when you take into account Hofstadter's Law. -- Hofstadter's Law
