lkml.org 
[lkml]   [1999]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRamdisk bug with msdos FS
Hi everybody,

building bootdisks, I struggled over a seemingly longstanding bug in the
ramdisk code. 2.0.36 shows exactly the same behaviour as 2.2.1 (-ac3). Both
are SMP kernels. util-linux-2.9h, kerneld resp. kmod and ramdisk loaded as a
modules as well as fat, msdos, vfat and minix filesystems. modutils-2.1.121
resp. 2.0.0

Create a ramdisk:
$ dd if=/dev/zero of=/dev/ram2 bs=512 count=2880
$ mkfs.msdos /dev/ram2 1440
mkfs.msdos produces a valid MS-DOS filesystem:
$ hex /dev/ram2 | less
0000 eb 3c 90 6d 6b 64 6f 73 66 73 00 00 02 04 01 00 ë<.mkdos fs......
0010 02 00 02 40 0b f8 03 00 eb 00 12 00 00 00 00 00 ...@.ø.. ë.......

You are able to mount it:
mount -t msdos /dev/ram2 /mnt/ram2

The filesystem is mounted and can be accessed:
$ df
/dev/ram2 1420 0 1420 0% /mount/ram
$ mount
/dev/ram2 on /mount/ram type msdos (rw)

However, if you have a look at /dev/ram2, you see that something's going
wrong:
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

THE MOUNT CALL HAS DESTROYED THE DATA IN /DEV/RAM2 !!!

Of course umounting does not help! The strange thing about it is, that this
happens for msdos and vfat, but not for ext2 or minix.

Now the ramdisk driver is confused. A subsequent mkfs.msdos succeeds, but
you are not able to mount the ramdisk. The next mkfs.minix and mount also
fails, but after this it has recovered. rmmod and insmod rd also help to get
the ramdisk driver working again, ie. allowing minix and ext2 mounts without
and msdos/vfat mounts with corruption again.

> mkfs.msdos /dev/ram2 1440
> mount -t /dev/ram2 /mnt/ram
> umount /dev/ram2
> mount -t /dev/ram2 /mnt/ram

The last mount fails, as the first one has destroyed the msdos filesystem.
The kernel says:

[MS-DOS FS Rel. 12,FAT 12,check=n,conv=b,uid=0,gid=0,umask=022,bmap]
[me=0x0,cs=0,#f=0,fs=0,fl=0,ds=0,de=0,data=0,se=0,ts=0,ls=0,rc=0,fc=4294967295]
Transaction block size = 512
VFS: Can't find a valid MSDOS filesystem on dev 01:02.

---

I'v even seen worse failures. Not specifying -t msdos, but relying on the
probing, I get an Oops in the hpfs module. It is patched for read-write
operation. I'll send a bug report to the author.

Subsequent mount,umount calls hang in the kernel: D state on down_failed.

---

I have no explanation, why minix and ext2 work perfectly with a ramdisk,
while msdos and vfat fail. I guess, msdos does an operation (seek behind
end, or whatever) that confuses the ramdisk driver.


I hope somebody is able to fix this!

I append a script to do tests with.

--
Kurt Garloff <kurt@garloff.de> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
#!/bin/bash

finish() {
echo "*** ABORT ***"
umount $device
freeramdisk $device
exit
}

export fstype=msdos
export device=/dev/ram2
export size=1440
test -z "$1" || fstype="$1"
test -z "$2" || device="$2"
test -z "$3" || size="$3"
echo "*** Test with filesystem $fstype on device $device, size $size ***"
dd if=/dev/zero of=$device bs=1024 count=$size 2>/dev/null
#mkdir /mnt/ram2
#ln -s /sbin/mkfs.msdos /sbin/mkfs.vfat
mkfs -t $fstype $device $size || finish
mount -t $fstype $device /mnt/ram2 || finish
cp /vmlinuz /System.map /mnt/ram2/
ls -lF /mnt/ram2
umount /mnt/ram2 || finish
ls -lF /mnt/ram2
# Now, watch it crash your kernel's VFS layer
mount -t $fstype $device /mnt/ram2 || finish
ls -lF /mnt/ram2
umount /mnt/ram2
freeramdisk $device
ls -lF /mnt/ram2
\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.021 / U:1.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site