Re: Error testing ext3 on brd ramdisk

Nick Piggin escribió:
On Mon, Mar 02, 2009 at 06:42:18PM +0100, Jorge Boncompte [DTI2] wrote:
Nick Piggin escribió:
On Fri, Feb 27, 2009 at 07:08:46PM +0100, Jorge Boncompte [DTI2] wrote:

I have added Nick Piggin to the CC: as maintainer of the brd driver.

After switching an embedded distribution that /etc on a ramdisk based minix filesystem from to 2.6.29-rcX i am too getting errors ant the filesystem is corrupted. Does not happen always. The visible effect with text files after reboot is getting the old version of the file and "\0"'s at the end.

Did you found a solution?
What architectures are you using? It's possible that brd is missing
a cacheflush. I test it pretty heavily on x86 and no problems, so
this might point to an arch specific problem.

drivers/block/brd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/block/brd.c
--- linux-2.6.orig/drivers/block/brd.c
+++ linux-2.6/drivers/block/brd.c
@@ -275,8 +275,10 @@ static int brd_do_bvec(struct brd_device
if (rw == READ) {
copy_from_brd(mem + off, brd, sector, len);
- } else
+ } else {
+ flush_dcache_page(page);
copy_to_brd(brd, mem + off, sector, len);
+ }
kunmap_atomic(mem, KM_USER0);

Hi, I am on 32bits x86, 2 x Xeon with HT CPUs, but I have seen the same corruption on a KVM/QEMU guest with single emulated CPU.

With your patch on top of vanilla 2.6.29-rc3+plus some networking patches I still get corruption sometimes.

The script that saves the configuration does...

mount -no remount,ro /dev/ram0
dd if=/dev/ram0 of=config.bin bs=1k count=1000
mount -no remount,rw /dev/ram0
md5sum config.bin
dd if=config.bin of=/dev/hda1
echo $md5sum | dd of=/dev/hda1 bs=1k seek=1100 count=32

on system boot

dd if=/dev/hda1 of=/dev/ram0 bs=1k count=1000
fsck.minix -a /dev/ram0
mount -nt minix /dev/ram0 /etc -o rw

I have never seen a MD5 failure on boot, just sometimes the filesystem is corrupted. Kernel config attached.

Hi Jorge,

Well I found and fixed something :) (see other mail) but I don't know
whether that applies to you here if you're running with a single CPU
and no preemption. But still, it might be worth trying that patch? I'm

I first saw the corruption on the 2 x Xeon system. I'll try it and let you know.

sorry I'm still unable to reproduce a problem with your script
(although you don't describe how you create the filesystem before
you remount it).

If the MD5Sum check fails the startup script copy a templated image of the filesystem contained on a file on another partition to the ramdisk.

From your description, it suggests that the corrupted image is being
read from /dev/ram0 (becuase the md5sum passes).

No, it is read from /dev/hda1.

In your script, can you run fsck.minix on config.bin when you first
create it? What if you unmount /dev/ram0 before copying the image?

Yesterday I did some tests and found that doing...

umount /etc (/etc is what is mounted from /dev/ram0)
dd if=/dev/zero of=/dev/ram0 bs=1k count=1000
mount /dev/ram0 /etc -t minix -o rw
...succeds and mounts a corrupted filesystem with the old content. Doing the same with the all ramdisk driver fails on mount with "no filesystem found".

If I do...
umount /etc (/etc is what is mounted from /dev/ram0)
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=/dev/ram0 bs=1k count=1000
mount /dev/ram0 /etc -t minix -o rw
... then the mount fails with no filesystem found as it should.

Does this ring any bell? :-)



Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at