On Feb 13, 2007 13:22 +0100, Aurelien Degremont wrote: > The behavior is: some of our tools do many fseek-fread(few bytes) on > large files in huge quantity. Those tools face very poor performances > regarding to what could have been expected with Lustre traditional > performance on the same configuration. > > > f = fopen() > pos = somewhere > do > fseek(f, pos) > fread(10 bytes, f) > pos = somewhere_else > loop > > > Analyzing the behavior, it appears that, for each small fread(), a > read of 2MB was done instead, by the glibc, this leading to poor > performance
Ah, interesting. I've seen similar reports, but didn't realize the problem was caused by glibc instead of the application itself using f_bsize. > [lustre/llite/llite_lib.c:1567] > inode->i_blkbits = min(PTLRPC_MAX_BRW_BITS+1, LL_MAX_BLKSIZE_BITS); > > The performances are really good using it when reducing the > value to 4KB. > Indeed, Lustre is really better managing and buffering itself the I/O > than the glibc in those cases. So, we are wondering whether it could not > be a good idea to reduce the default value, or using something like a > module param to tune it depending on the kind of I/O on the client. We haven't tested the performance of such a change under different loads, so I can't really comment. The original reason that i_blkbits was increased was because programs like "cp" benefit a great deal with a larger blocksize. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Lustre-devel mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-devel
