Date: Sat, 24 May 2008 13:56:05 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Martin Laabs <martin.laabs@mailbox.tu-dresden.de> Cc: freebsd-bugs@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: misc/123939: msdosfs corruptes new files Message-ID: <20080524134012.L69478@delplex.bde.org> In-Reply-To: <200805231916.m4NJGVXP001708@www.freebsd.org> References: <200805231916.m4NJGVXP001708@www.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080524134012.L69478>