Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Jul 2003 01:00:29 -0700 (PDT)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/55028: The broken FAT12 filesystem causes system panic onFreeBSD 4.8-RELEASE and 5.1-CURRENT
Message-ID:  <200307310800.h6V80TLn093308@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/55028; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: Portnoy Alexander <Tel-Hai@mail.ru>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/55028: The broken FAT12 filesystem causes system panic
 onFreeBSD 4.8-RELEASE and 5.1-CURRENT
Date: Thu, 31 Jul 2003 17:58:03 +1000 (EST)

 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307310800.h6V80TLn093308>