misc/123939: msdosfs corruptes new files

[Bruce Evans]

On Fri, 23 May 2008, Martin Laabs wrote:

>> Description:
> If I mount my USB mass storage device (a MP3-Player in my case) and create some files they get corrupted. I can nearly exclude a defect since the device worked with fine the 6.3 RELEASE and also works if I copy files with Windows.
> There is also an other strange behaviour. Some time I mount the device to i.e. /mnt but if I ls the directory it is empty (but mount says the device is mounted.) If I demount the device and mount it i.e. to /dos I can access the files. Although some directories are marked as files and can therfore be not accessed.
> I checked the device with the microsoft scandisc and it reported no errors. However fsck_msdosfs claims an "Invalid signature in boot block: 0000".
>
> Reading of the device does work, expect of the directory problem, properly.

Please limit line lengths to considerably less than 300+ characters.

This is probably a bug in the umass or da driver. da claims to support i/o's
of DFLTPHYS = 64K, so lower level drivers must support this even if the
hardware doesn't, but apparently some usb drives have a lower limit.

Can you verify that this is the problem by trying another type of file
system (ffs is simplest) or by doing direct i/o?

Some cases can probably be worked around by mounting with -noclusterr
-noclusterw, but these options are broken for msdosfs in FreeBSD[6-7].
These options limit the i/o size for ordinary reads and writes but not
for mmapped reads and writes.

>> How-To-Repeat:
> # dd if=/dev/zero of=/dev/da7s1 bs=128k
> dd: /dev/da7s1: short write on character device
> dd: /dev/da7s1: end of device
> 7410+0 records in
> 7409+1 records out
> 971120640 bytes transferred in 1399.775541 secs (693769 bytes/sec)

If you can do this, then you can check if direct i/o works (I think it
doesn't).  Write a test pattern (not zeros) and try to read it back.
A couple of 64K or 128K-blocks are enough.

> # newfs_msdos /dev/da7s1
> /dev/da7s1: 473246 sectors in 236623 FAT32 clusters (4096 bytes/cluster)
> bps=2048 spc=2 res=8 nft=2 mid=0xf0 spt=32 hds=64 hid=0 bsec=474180 bspf=463
> rdcl=2 infs=1 bkbs=2

newfs_msdosfs uses direct i/o's, but they are too small to cause the
problem that I'm thinking of.

Bruce