Summary: | [msdosfs] corrupts new files | ||
---|---|---|---|
Product: | Base System | Reporter: | Martin Laabs <martin.laabs> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Open --- | ||
Severity: | Affects Only Me | ||
Priority: | Normal | ||
Version: | 7.0-RELEASE | ||
Hardware: | Any | ||
OS: | Any |
Description
Martin Laabs
2008-05-23 20:20:03 UTC
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 |