From owner-freebsd-current@FreeBSD.ORG Sun Apr 4 13:56:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 584EC16A4CE for ; Sun, 4 Apr 2004 13:56:49 -0700 (PDT) Received: from mx.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D77E43D49 for ; Sun, 4 Apr 2004 13:56:48 -0700 (PDT) (envelope-from mb@imp.ch) Received: from mx2.imp.ch (mx.imp.ch [157.161.9.64]) by mx.imp.ch (8.12.10/8.12.10) with ESMTP id i34KtxEc070165; Sun, 4 Apr 2004 22:56:00 +0200 (CEST) (envelope-from mb@imp.ch) Received: from imp.ch (cvs.imp.ch [157.161.4.9]) by mx2.imp.ch (8.12.10/8.12.10/Submit) with ESMTP id i34Ktv6W070131; Sun, 4 Apr 2004 22:55:57 +0200 (CEST) (envelope-from mb@imp.ch) Date: Sun, 4 Apr 2004 22:55:59 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20040404224036.K37637@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: No X-Scanned-By: MIMEDefang 2.41 X-Virus-Scanned: clamd / ClamAV version devel-20040327, clamav-milter version 0.70b X-Spam-Status: No, hits=-4.9 required=50.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mx1.imp.ch cc: dillon@backplane.com Subject: Possible race in the filesystem code (softupdates) ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 20:56:49 -0000 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