From nobody@FreeBSD.org  Fri May 23 19:18:00 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0E1FB106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 May 2008 19:18:00 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id DE0018FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 May 2008 19:17:59 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m4NJGVTN001709
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 May 2008 19:16:31 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m4NJGVXP001708;
	Fri, 23 May 2008 19:16:31 GMT
	(envelope-from nobody)
Message-Id: <200805231916.m4NJGVXP001708@www.freebsd.org>
Date: Fri, 23 May 2008 19:16:31 GMT
From: Martin Laabs <martin.laabs@mailbox.tu-dresden.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: msdosfs corruptes new files
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         123939
>Category:       kern
>Synopsis:       [msdosfs] corrupts new files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-fs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 23 19:20:03 UTC 2008
>Closed-Date:    
>Last-Modified:  Mon May 18 04:28:30 UTC 2009
>Originator:     Martin Laabs
>Release:        7.0-RELEASE-p1
>Organization:
>Environment:
FreeBSD martin.laabs 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

Muvo V100 MP3 Player
>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.
>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


>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: vwe 
State-Changed-When: Fri May 23 21:44:40 UTC 2008 
State-Changed-Why:  

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 
Responsible-Changed-By: vwe 
Responsible-Changed-When: Fri May 23 21:44:40 UTC 2008 
Responsible-Changed-Why:  

track 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123939 

From: Bruce Evans <brde@optusnet.com.au>
To: Martin Laabs <martin.laabs@mailbox.tu-dresden.de>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: misc/123939: msdosfs corruptes new files
Date: Sat, 24 May 2008 13:56:05 +1000 (EST)

 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 
State-Changed-By: vwe 
State-Changed-When: Sun May 25 19:58:28 UTC 2008 
State-Changed-Why:  

feedback received 


Responsible-Changed-From-To: vwe->freebsd-bugs 
Responsible-Changed-By: vwe 
Responsible-Changed-When: Sun May 25 19:58:28 UTC 2008 
Responsible-Changed-Why:  

back to pool, noting Bruce has had a discussion about that PR 
on bugs@ and is investigating this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123939 
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon May 18 04:28:24 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=123939 
>Unformatted:
