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. 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) # 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 # mount -tmsdosfs /dev/da7s1 /mnt # cp /media/Music/Tony/Duncan\ Sheik\ -\ White\ Limousine/01\ -\ Hey\ Casanova.mp3 /mnt # diff /media/Music/Tony/Duncan\ Sheik\ -\ White\ Limousine/01\ -\ Hey\ Casanova.mp3 /mnt # umount /mnt # mount -tmsdosfs /dev/da7s1 /mnt # diff /media/Music/Tony/Duncan\ Sheik\ -\ White\ Limousine/01\ -\ Hey\ Casanova.mp3 /mnt Files /media/Music/Tony/Duncan Sheik - White Limousine/01 - Hey Casanova.mp3 and /mnt/01 - Hey Casanova.mp3 differ
State Changed From-To: open->feedback Martin, as a starting point, please give us a dmesg (verbose boot) and an idea about the slice table of your device (fdisk /dev/da7). Also show us output of `mount` while the device is mounted. Please note, there are flash memory devices on the market with unreliable memory and/or badly formatted FAT filesystems. You may want to check if zero'ing (dd if=/dev/zero of=/dev/da7), reslicing (fdisk) and newfs'ing your device makes a difference. For the records: I do have a memory stick here laying around which shows a similar effect (when mounted by volume label or device name it shows different files). Still, this issue might be a umass problem, if not hardware related or caused by a bad filesystem.
Responsible Changed From-To: freebsd-bugs->vwe track
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
State Changed From-To: feedback->open feedback received
Responsible Changed From-To: vwe->freebsd-bugs back to pool, noting Bruce has had a discussion about that PR on bugs@ and is investigating this.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped