kern/122961: write operation on msdosfs file system causes panic

Bruce Evans brde at optusnet.com.au
Thu Apr 24 03:57:15 UTC 2008


On Wed, 23 Apr 2008, Dominic Fandrey wrote:

> Bruce Evans wrote:
>> The broken nocluster* can be worked around by upgrading to a version of
>> mount_msdsosfs(8) that hasn't been broken by using nmount(2).
>> mount_msdsosfs(8) from RELENG_5 should work.
>
> I feel reluctant about downgrading to 5.x mount_msdosfs,

But it would be an upgrage :-).  Anyway, running mount_msdosfs on one
disposable file system that might panic should be safe.

> however I can 
> confirm that cp with large files does _not_ cause a panic. As far as I 
> understand this confirms your theory.

Not quite.  I would have expected the problem to affect read() and write()
too unless the file system is mounted with -nocluster*.

> How can I provide more useful information?

Check if the cp of large files actually works.  A previous report mentioned
data corruption but I don't remember it saying anything about panics.  Maybe
mmap() does something different that causes more serious corruption.

I'll have to think more about adding debugging code to mmap() and the
device driver.

Meanwhile, can you try changing this code in msdosfs_vnops.c:

%%%
 	mp = vp->v_mount;
 	maxio = mp->mnt_iosize_max / mp->mnt_stat.f_iosize;
 	bnpercn = de_cn2bn(pmp, 1);
%%%

o Add a printf to print out maxio (might need rate limiting).
o Try lower values of maxio until you find the largest one that works
   (keep dividing by 2.  Only try one value per boot or per mount of
   course).  I think it is always 128K initially, and small values will
   work.  A value of the cluster size (typically 4K) or smaller should
   give the old behaviour.

or one or more of the following:

o Check that large i/o's to the raw device work.
o Check for the problem with other file systems that implement clustering.
   ffs is easiest.
o On an older version of FreeBSD that doesn't seem to have the problem,
   check for the problem with msdosfs with a large cluster size (the
   cluster can be up to 64K, which is large enough to show the problem that
   I suspect).   Check on file systems that implement clustering too (now
   the block size doesn't need to be large to cause large i/o's).

Bruce


More information about the freebsd-bugs mailing list