Skip site navigation (1)Skip section navigation (2)
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>