From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 07:06:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E473716A4CE for ; Wed, 7 Jul 2004 07:06:11 +0000 (GMT) Received: from kozubik.com (kozubik.com [65.248.2.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4BAA43D55 for ; Wed, 7 Jul 2004 07:06:11 +0000 (GMT) (envelope-from john@kozubik.com) Received: from kozubik.com (john@localhost [IPv6:::1]) by kozubik.com (8.12.3/8.12.3) with ESMTP id i6774GBx032175 for ; Wed, 7 Jul 2004 00:04:16 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.12.3/8.12.3/Submit) with ESMTP id i6774FJY032172 for ; Wed, 7 Jul 2004 00:04:15 -0700 (PDT) Date: Wed, 7 Jul 2004 00:04:14 -0700 (PDT) From: John Kozubik To: freebsd-hackers@freebsd.org Message-ID: <20040706224911.F806-100000@kozubik.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: rapid file creation on snapshotted filesystems panics lockmgr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2004 07:06:12 -0000 (the below refers exclusively to 5.2.1-RELEASE) Rapid file creation on filesystems with as few as one snapshot on them will panic lockmgr: panic: lockmgr: locking against myself cpuid = 0; syncing disks, buffers remaining... panic: ffs_copyonwrite: recursive call cpuid = 0; uptime: 5m10s Shutting down ACPI (crash) ----- I have repeated this problem on both a laptop and a server, with both IDE and SCSI disks, and with both a GENERIC and a pared down kernel (no additions, simply subtractions). Further, disabling ACPI by adding hint.acpi.0.disabled="1" to the file /boot/loader.conf did not help in any way. All tested systems were single processor Pentium-3 systems. Here is how you can quickly recreate this problem: mksnap_ffs /mnt/mount1 /mnt/mount1/snapshot_1 cd /mnt/mount1 tar cvf /mnt/mount1/devel.tar /usr/ports/devel tar xvf devel.tar You will panic the system and (possibly) receive the above output within seconds. ----- If you do not immediately panic the system, the tar process will be blocked: procs memory page disks r b w avm fre flt re pi po fr sr da0 fd0 0 1 0 37816 29160 3 0 0 0 33 25 0 0 and will be in state "snaplk" : PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 598 root -4 0 1660K 1088K snaplk 1:00 0.00% 0.00% tar It will be impossible to kill the tar process. Further, any additional tar processes will immediately block (the counter will increment to 2 in `vmstat` output). Any attempt to `sync` will also result in a blocked `sync` process in state "snaplk". You will not be able to successfully reboot, as the system will lock when it the shutdown process attempts to sync. ----- To reproduce this error, it is necessary to create small files rapidly, as I did above by tarring and untarring the /usr/ports/devel directory. If you dd several very large files and tar them up, and then untar them in the filesystem that has been snapshotted, this panic will not occur - even though the total amount of data is much larger than what is contained in a tarball of /usr/ports/devel. I have submitted this as PR misc/68757. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com