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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
