Chris Mason wrote: > > Anyway, Anne, could you please take a look and make sure this still > improves your performance? I think the odd results you got for 2.4.12 > before were probably due to actual fragmentation against prellocated > blocks from other files. With a single writer, 2.4.13 allocates blocks > in order during the open, append, close loop for me. >
Hi Chris, Thanks, I had switched over to almost the same code after your suggestion. (Much nicer!) I will try this patch. The 2.4.12 results actually turned out to have reallocated the prealloc blocks to the same file, but out of order. I think the reason for this is that the NFS client sent a bunch of NFS write requests asynchronously and multiple NFSD threads sent the writes down to reiserfs out of order. Since I was loopback mounting, the client for each kernel was the same as the server version. I don't see a difference on a quick look, but I'll see if I can figure out the difference during testing. I noticed that Trond has 2 patches http://www.fys.uio.no/~trondmy/src/2.4.13/linux-2.4.13-tune.dif and http://www.fys.uio.no/~trondmy/src/2.4.13/linux-2.4.13-write.dif that will be interesting to try and see the results. If NFS continues to send writes to reiserfs out of order, an NFS specific optimization would be to allocate the disk blocks that would be appropriate for keeping the file data contiguous if the new file data being written is within a short number of blocks from the current end of the file. Thanks again for the help! Anne
