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

[Dominic Fandrey]

Bruce Evans wrote:
> 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.

If it really is of help, I will downgrade. Not before the weekend, though.

>> 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 copied a 1.2gb DVD rip and watched it afterwards. No corruption. Md5 
checksums show that the file on the stick and the original are identical.

> 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.

I will give it a try.

> 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
> 

These ones are harder. I will also defer them to the weekend.