[EMAIL PROTECTED] wrote:
Not sure it is relevant, but there was also some discussion about an fseek glibc optimisation last year : http://lkml.org/lkml/2006/2/28/187 "Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?"
This is perfectly relevant because it seems Reiser hit exactly the same issue with ReiserFS (the value jumped from 4K in 2.4 to 128K in 2.6).
The solution I propose for Lustre is : As Lustre could buffer the I/O greatly better than the glibc, why not return a small value for stat.blksize and let Lustre manage the different I/O pattern. Does another code uses the value stat.blksize return by statfs() except GlibC ?
-- Aurelien Degremont _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
