NetBSD Problem Report #16401

Received: (qmail 11235 invoked from network); 18 Apr 2002 16:50:23 -0000
Message-Id: <20020418163756.3889.qmail@silence.homedns.org>
Date: 18 Apr 2002 16:37:56 -0000
From: klaus.heinz@onlinehome.de
Reply-To: klaus.heinz@onlinehome.de
To: gnats-bugs@gnats.netbsd.org
Subject: filesystem corrupt after 'rm' with msdosfs on vnd
X-Send-Pr-Version: 3.95

>Number:         16401
>Category:       kern
>Synopsis:       filesystem corrupt after 'rm' with msdosfs on vnd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 18 16:51:00 +0000 2002
>Closed-Date:    Sat Oct 19 19:26:24 +0000 2024
>Last-Modified:  Sat Oct 19 19:26:24 +0000 2024
>Originator:     Klaus Heinz
>Release:        NetBSD 1.5.2
>Organization:
none
>Environment:
System: NetBSD silence.homedns.org 1.5.2 NetBSD 1.5.2 (SILENCE) #5: Sun Mar
24 01:45:43 MET 2002 root@silence.homedns.org:/var/tmp2/src-1.5.2/sys/arch/
i386/compile/SILENCE i386

>Description:
	Using fsck_msdos and newfs_msdos on a vnd device does not
	work correctly. After some simple operations on the created
	filesystem, like 'rm', the filesystem is corrupted. The errors
	fsck reports are not always for the same files or in the same
	phases of the check.
	Doing the same on /dev/fd0b works for me.

	There seems to be a MACHINE- or MACHINE_ARCH-specific problem, because
	to my surprise this worked flawlessly both on NetBSD/Amiga 1.5.2
	and 1.5ZC (sources from 2002-04-16). I don't have -current on i386
	to test it.

>How-To-Repeat:
	Use this little script as user 'root':

	  #!/bin/sh
	  dd if=/dev/zero of=/var/tmp/img.vnd bs=512x18x2 count=80
	  newfs_msdos -f 1440 /var/tmp/img.vnd
	  vnconfig vnd0 /var/tmp/img.vnd 512/18/2/80
	  fsck_msdos -y /dev/rvnd0a
	  mount_msdos /dev/vnd0a /mnt
	  for i in 0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j;
	  do echo test > /mnt/$i.txt;
	  done
	  rm /mnt/[4-5].txt /mnt/[d-g].txt
	  umount /mnt
	  fsck_msdos -y /dev/rvnd0a
	  vnconfig -u vnd0


	Output on NetBSD/i386 1.5.2:

	  # sh /var/tmp/msdos.sh
	  80+0 records in
	  80+0 records out
	  1474560 bytes transferred in 1 secs (1474560 bytes/sec)
	  ** /dev/rvnd0a
	  ** Phase 1 - Read and Compare FATs
	  ** Phase 2 - Check Cluster Chains
	  ** Phase 3 - Checking Directories
	  ** Phase 4 - Checking for Lost Files
	  1 files, 1423 free (2847 clusters)
	  ** /dev/rvnd0a
	  ** Phase 1 - Read and Compare FATs
	  Cluster 120 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 325 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 517 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 684 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 798 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 904 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 965 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  Cluster 1012 is marked free in FAT 0, as EOF in FAT 1
	  use FAT 0's entry? yes
	  ** Phase 2 - Check Cluster Chains
	  ** Phase 3 - Checking Directories
	  /0.TXT starts with free cluster
	  Truncate? yes
	  /2.TXT starts with free cluster
	  Truncate? yes
	  /3.TXT starts with free cluster
	  Truncate? yes
	  /7.TXT starts with free cluster
	  Truncate? yes
	  /8.TXT starts with free cluster
	  Truncate? yes
	  /H.TXT starts with free cluster
	  Truncate? yes
	  /I.TXT starts with free cluster
	  Truncate? yes
	  /J.TXT starts with free cluster
	  Truncate? yes
	  ** Phase 4 - Checking for Lost Files
	  Update FATs? yes
	  Unable to write FAT (Read-only file system)
	  ***** FILE SYSTEM WAS MODIFIED *****

>Fix:
	none
>Release-Note:
>Audit-Trail:

From: Klaus Heinz <k.heinz.nov.zwei@onlinehome.de>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/16401: filesystem corrupt after 'rm' with msdosfs on vnd
Date: Sun, 10 Nov 2002 21:12:35 +0100

 Hi,

 the problem is still there with 1.5.4_ALPHA, sources from 2002-10-30.

 ciao
      Klaus
Responsible-Changed-From-To: kern-bug-people->bouyer
Responsible-Changed-By: bouyer@netbsd.org
Responsible-Changed-When: Sun, 10 Apr 2005 17:53:43 +0000
Responsible-Changed-Why:
.


State-Changed-From-To: open->feedback
State-Changed-By: bouyer@netbsd.org
State-Changed-When: Sun, 10 Apr 2005 17:53:43 +0000
State-Changed-Why:
Hi,
browsing vnd-related PRs, I noticed this one. Is it still a problem ?
I've used vnd to build msdos images on newer NetBSD releases and didn't run
into this ...


Responsible-Changed-From-To: bouyer->kern-bug-people
Responsible-Changed-By: bouyer@netbsd.org
Responsible-Changed-When: Wed, 20 Apr 2005 20:57:13 +0000
Responsible-Changed-Why:
This problem is beyond my skills


State-Changed-From-To: feedback->open
State-Changed-By: bouyer@netbsd.org
State-Changed-When: Wed, 20 Apr 2005 20:57:13 +0000
State-Changed-Why:
Klaus provided feedback in private mail; the problem does still exists.


State-Changed-From-To: open->closed
State-Changed-By: jakllsch@NetBSD.org
State-Changed-When: Sat, 19 Oct 2024 19:26:24 +0000
State-Changed-Why:
This problem is due to the disklabel sector write protection not being disabled on the vnd(4) and using slice 'a' instead of RAW_PART.  Since 2016 msdosfs has spewed error messages if the FAT write fails, so the cause of the problem should be more apparent to users now.


>Unformatted:

Home	PR Database Search