From owner-freebsd-bugs@FreeBSD.ORG Thu Jul 31 00:58:14 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC77E37B401; Thu, 31 Jul 2003 00:58:14 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E1EA43F93; Thu, 31 Jul 2003 00:58:13 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA06121; Thu, 31 Jul 2003 17:58:04 +1000 Date: Thu, 31 Jul 2003 17:58:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Portnoy Alexander In-Reply-To: <20030730023223.12b35ab1.Tel-Hai@mail.ru> Message-ID: <20030731173103.D5677@gamplex.bde.org> References: <20030730023223.12b35ab1.Tel-Hai@mail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/55028: The broken FAT12 filesystem causes system panic onFreeBSD 4.8-RELEASE and 5.1-CURRENT X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2003 07:58:15 -0000 On Wed, 30 Jul 2003, Portnoy Alexander wrote: > >Description: > The broken FAT12 filesystem (the image is attached) causes > system panic on FreeBSD 4.8-RELEASE and 5.1-CURRENT. > It happens when I mount the filesystem via vnode or directly > from the floppy disk and execute 'ls /mnt/floppy'. This file system has many errors. It works OK when checked and cleaned by fsck_msdosfs before mounting (except fsck_msdosfs removes all its files :-). I think running fsck on dirty file systems is just as much a requirement for msdosfs as for ffs. Neither of these file systems does many consistency checks so inconsistencies may cause panics even for readonly mounts, and if either of these file systems becomes more robust then it is likely to be ffs first. The crash is just nastier than usual in this case (for me under 5.1, it hangs in the middle of printing a message). I may investigate this more using BREAK_TO_DEBUGGER. msdosfs doesn't have a dirty flag, so fscking for it doesn't work quite as well as for ffs. ISTR a PR about merging someone's (Apple's?) implementation of the dirty flag for msdosfs. I don't completely trust fsck_msdosfs and never run it automatically at boot time, but I've never seen it make things worse, except possibly here where it deletes everything (due to not being able to create LOST.DIR?) and doesn't fix the final error ("Invalid long filename entry at end of directory"). Bruce