From owner-freebsd-hackers  Thu Nov 28 03:12:12 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA20651
          for hackers-outgoing; Thu, 28 Nov 1996 03:12:12 -0800 (PST)
Received: from eac.iafrica.com (196-7-192-184.iafrica.com [196.7.192.184])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA20644
          for <freebsd-hackers@freebsd.org>; Thu, 28 Nov 1996 03:12:01 -0800 (PST)
Received: (from rnordier@localhost) by eac.iafrica.com (8.7.6/8.6.12) id NAA00867; Thu, 28 Nov 1996 13:07:35 +0200 (SAT)
From: Robert Nordier <rnordier@iafrica.com>
Message-Id: <199611281107.NAA00867@eac.iafrica.com>
Subject: Re: A simple way to crash your system.
In-Reply-To: <199611280947.KAA01216@uriah.heep.sax.de> from J Wunsch at "Nov 28, 96 10:47:56 am"
To: j@uriah.heep.sax.de (J Wunsch)
Date: Thu, 28 Nov 1996 13:07:34 +0200 (SAT)
Cc: freebsd-hackers@freebsd.org, rnordier@iafrica.com
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

J Wunsch wrote:

> As Robert Nordier wrote:
> 
> > By default, msdosfs would in future not mount DOS FSes with a block
> > size exceeding 32 (or maybe 16) sectors, since these appear to be
> > the filesystems that trigger the UFS corruption problem.
> > 
> > However, to revert to present behavior (ie. mount any DOS partition),
> > either:
> > 
> >    (a) Use mount(8) or mount_msdos(8) with the -f (force) option; or 
> >    (b) Specify MSDOSFS_FORCE as a kernel configuration option.
> 
> Assuming it's documented in LINT, GENERIC, and mount_msdos(8), i think
> this is a fine compromise.

I see John Dyson has committed a change to trap FS buffer requests
larger than the vfs layer is set up to handle, and increased MAXBSIZE
(where MSDOSFS is defined) to 32768.

Anyone know if John's change does anything to eliminate the `MSDOSFS
corrupts UFS' problem?  (I've never been able to reproduce it here.)

If the change doesn't eliminate the corruption, the problem may
not be directly related to MAXBSIZE.  In which case, restricting
the MSDOSFS to supporting only DOS 3.30 (less than 32MB) partitions
(unless "forced") may be the logical and/or safest step.

--
Robert Nordier