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
