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]--PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Description: crash_msdos.sh Content-Disposition: attachment; filename="crash_msdos.sh"
#!/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
--PEIAKu/WMn1b1Hv9--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/