Possible race in the filesystem code (softupdates) ?

Matthew Dillon dillon at apollo.backplane.com
Sun Apr 4 14:45:01 PDT 2004

:During testing I found that the following procedure is pretty dangerous
:and leads sometimes to a panic():
:cd /usr/ports/editors/openoffice-1.1
:make patch
:mv work work.old
:rm -rfd work.old &
:make patch &
:find work.old > /dev/null 2>&1
:The filesystem was mounted with softupdates.
:I'm trying to reproduce it tomorrow for a useful dump. I had it happen twice but
:was not able to take any notices because it happenend on a productive server.
:I can exclude any hardware problems. We use current from a week ago.
:Find(8) seems to trigger that bug while we are deleting this really huge
:work dir with ~200000 files in it and doing a stat on it at the same
:I'd call the bug pretty serious. I'll post more info after I got one
:more panic.
:Some other thing that scares me is that reading a filesystem with many many
:little files (as the openoffice work dir) slows down all IO operations. At
:BSDCon Matt Dillon talked to me about this issue and about his plan to solve it.
:Matt, did you make any progress here ? It is really scaring how slow UFS is
:in this area.

    Very interesting.  I'm assuming this is on FreeBSD-current?  I'm not
    sure I can help vis-a-vie panics on FreeBSD-current, but I will run
    your test loop on DFly and if it panics I'll track it down and email you
    and Kirk.

    You didn't post what the panic was or the register dump or ddb trace,
    so I can only guess at this point.   If/when you get the information,
    please Cc: me, I might be able to contribute something.

    I don't quite recall what the issue was with regards to slow I/O,
    but I am guessing that the exclusive lock on the directory is creating
    stalls.  Make sure that dirhash is turned on, that will help.  Another
    issue may be the access time updates for the inodes, try mounting with
    noatime to see if that makes a difference.

    The only way to get rid of the exclusive directory lock is to introduce
    a namecache level namespace 'reservation' feature.  Then system calls
    like rename, rm, file create, and so forth can simply reserve the
    namespace and not keep an exclusive lock on the directory.  This is 
    what I plan to do in DragonFly (but I haven't done it yet).

					Matthew Dillon 
					<dillon at backplane.com>

More information about the freebsd-current mailing list