Date: Wed, 6 Aug 2003 13:43:32 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Tim Robbins <tjr@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: MSDOSFS woes Message-ID: <20030806104332.GA42110@sunbay.com> In-Reply-To: <20030806100552.GA59205@dilbert.robbins.dropbear.id.au> References: <20030802150850.GB20186@sunbay.com> <20030806100552.GA59205@dilbert.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 06, 2003 at 08:05:52PM +1000, Tim Robbins wrote: > On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: >=20 > > Gang, :-) > >=20 > > While working with Marcel on a bootable CD-ROM for IA64 issue, > > I've stumbled upon the following problem. I needed to increase > > the size of the EFI partition (which is an MS-DOS file system) > > to 64M, and that made two of my machines stuck solidly -- a lot > > of process are waiting on the "wdrain" event. >=20 > Interesting. Were you running with INVARIANTS on? I got a completely > reproducible kernel panic when running your script, regardless of whether= I > used -F 12 or -F 16; it was trying to write file data past the end of the= disk, > and causing kernel memory pool to become corrupted. I was seeing Memory > modified after free errors, with blocks most recently used by GEOM and fi= le > desc. >=20 > Were you running the script with INVARIANTS on? >=20 My kernel config includes the GENERIC config which has INVARIANTS on. Further analysis of the problem shows that there are actually two problems. First problem is with newfs_msdos(8) (and kernel part of MSDOSFS). newfs_msdos(8) sometimes results in a bad file system lying about the number of available sectors (recorded in sector 0) than is actually available, as was demonstrated by Bruce Evans (and I've been able to reproduce this). Sometimes, this results in warnings =66rom MSDOSFS on a console, immediately followed by a panic. Sometimes, I also saw the "Memory modified after free". IIRC, I ended up with a conclusion that -s arguments >32M are unsafe with newfs_msdos(8). Second problem is with vnode-backed md(4) devices, and it is not MSDOSFS-specific. I've been able to reproduce the "wdrain" lockup after attempting to newfs(8) and fill (with cpio(1)) an 11MB-only vnode-backed UFS file system yesterday. Sometimes it just works, and sometimes it causes a lock-up. I asked Poul-Henning to look into this issue in a private message to him with more details and a test case. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/MNvUUkv4P6juNwoRArxcAJ966/J66GzRz8wUoQIcGKYfXP8KfACfennK EjBwmWLCXL2uglWvZu2uN5A= =e7ZV -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030806104332.GA42110>