Date: Sun, 4 Apr 2004 14:45:01 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Martin Blapp <mb@imp.ch> Cc: current@freebsd.org Subject: Re: Possible race in the filesystem code (softupdates) ? Message-ID: <200404042145.i34Lj1p4089167@apollo.backplane.com> References: <20040404224036.K37637@cvs.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hi,
:
: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
:time.
:
: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.
:
:Martin
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).
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404042145.i34Lj1p4089167>