Messages in this thread | | | Date | Tue, 19 Feb 2008 13:41:52 -0500 | From | Mark Lord <> | Subject | Re: very poor ext3 write performance on big filesystems? |
| |
Mark Lord wrote: > Theodore Tso wrote: > .. >> The following ld_preload can help in some cases. Mutt has this hack >> encoded in for maildir directories, which helps. > .. > > Oddly enough, that same spd_readdir() preload craps out here too > when used with "rm -r" on largish directories. > > I added a bit more debugging to it, and it always craps out like this: > opendir dir=0x805ad10((nil)) > Readdir64 dir=0x805ad10 pos=0/289/290 > Readdir64 dir=0x805ad10 pos=1/289/290 > Readdir64 dir=0x805ad10 pos=2/289/290 > Readdir64 dir=0x805ad10 pos=3/289/290 > Readdir64 dir=0x805ad10 pos=4/289/290 > ... > Readdir64 dir=0x805ad10 pos=287/289/290 > Readdir64 dir=0x805ad10 pos=288/289/290 > Readdir64 dir=0x805ad10 pos=289/289/290 > Readdir64 dir=0x805ad10 pos=0/289/290 > Readdir64: dirstruct->dp=(nil) > Readdir64: ds=(nil) > Segmentation fault (core dumped) > > Always. The "rm -r" loops over the directory, as show above, > and then tries to re-access entry 0 somehow, at which point > it discovers that it's been NULLed out. > > Which is weird, because the local seekdir() was never called, > and the code never zeroed/freed that memory itself > (I've got printfs in there..). > > Nulling out the qsort has no effect, and smaller/larger > ALLOC_STEPSIZE values don't seem to matter. > > But.. when the entire tree is in RAM (freshly unpacked .tar), > it seems to have no problems with it. As opposed to an uncached tree. ..
I take back that last point -- it also fails even when the tree *is* cached.
| |