Comment 81 for bug 330824

On Wed, 2009-04-15 at 13:42 +0000, Theodore Ts'o wrote:
> I'll note that part of the problem is that it doesn't seem to be
> trivially reproducible even on Ubuntu Jaunty.

It seems to reproduce here when two processes are removing files/trees
from the same filesystem. And as another comment suggests, my
filesystem is pretty damn full (98%) too, so maybe that's the key
factor.

> On my side, I still need to figure out why a Ubuntu Jaunty kernel built
> with my custom "no modules" config causes a black screen lockup when
> booting on an Ubuntu Intrepid userspace --- or find room to do an
> install of Ubuntu Jaunty beta and try to reproduce the problem myself.
> Oh, and I have to get my taxes filed too, and expense reports, and lots
> of other things related to my day job (which doesn't include ext4; it's
> been a long time since anyone has paid me to work on ext4 as my day job
> -- it's something I do in my copious spare time in the evenings or when
> I have a few spare moments).

I hear ya. I didn't at all mean to suggest that you (Ted) should be
working to fix this (indeed, your volunteered contributions on the bug
are significant in it's progress), but hopefully somebody who's getting
paid to work on Ubuntu Linux could devote some time to it.

Ted: As to your other question about allocation during removal, I tend
to doubt in my case there was. This is an archive/backup filesystem in
my case and the parallel (but not racing) deletes happen after the
backup run, so there shouldn't be any allocation happening at that time.

Ted: FWIW, you might (or might not) recall we discussed the speed of
deleting hardlink trees in ext3 vs. XFS a few months ago when I was
switching to XFS specifically for deletes speed... well, a few XFS
crashes (and one almost 24 hour xfs_repair) later I am back in the ext*
fold on ext4 and happy to report that XFS was just as slow as ext3 and
ext4 beats them both hands down at deleting big (many) hard linked trees
of files.