RE: ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes

From: Torrey Hoffman (torrey.hoffman@myrio.com)
Date: Tue Dec 18 2001 - 15:14:49 EST


More information! And a workaround!

I conjecture that the ramdisk driver (post 2.4.9) only grabs
VM pages properly if it is accessed directly, as a dd to
/dev/ram0 does. I further conjecture that accessing the
ramdisk through a mounted filesystem does not grab pages
properly.

The reason I believe this is that removing the call to
"freeramdisk" from my original script avoids corruption.

Another way to avoid ramdisk corruption is to
"dd if=/dev/zero of=/dev/ram0 bs=1k count=4000"
immediately after the call to freeramdisk.

If my conjecture is right, then the corruption is caused
because mke2fs on a "freed" /dev/ram0 doesn't touch every
block of the fs, leaving "holes" where pages are not properly
grabbed from the VM. The resulting filesystem appears to work,
but dd'ing from /dev/ram0 gets a broken filesystem image.

Note that "freeramdisk /dev/ram0" is pretty much just:
#define FLKFLSBUF _IO(0x12,97) /* flush buffer cache */
f = open("/dev/ram0", O_RDWR);
ioctl(f, BLKFLSBUF);

To experiment for yourself, stick the following script in
a subdirectory which also contains a "testdir" directory
with about 3 MB of data.

- - - - - - - -
#!/bin/bash

# to tickle the bug, do the freeramdisk but not the
# dd from /dev/zero to /dev/ram0.

freeramdisk /dev/ram0
#dd if=/dev/zero of=/dev/ram0 bs=1k count=4000

mke2fs -m0 /dev/ram0 4000
mount -t ext2 /dev/ram0 /mnt/ramdisk
rm -rf /mnt/ramdisk/*

cp -a ./testdir /mnt/ramdisk
umount /dev/ram0

dd if=/dev/ram0 of=ram0.img bs=1k count=4000
dd if=ram0.img of=/dev/ram0 bs=1k count=4000

mount -t ext2 /dev/ram0 /mnt/ramdisk
diff -q -r ./testdir /mnt/ramdisk/testdir

# If diff reports mismatches, you saw the bug.

umount /dev/ram0
- - - - - - - -

If the gods of the VM and VFS don't bother to look at
it, I might take a peek at the relevant kernel code myself.
Might take two months of study before I know enough though.

Torrey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:17 EST