public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Niehusmann <jan@gondor.com>
To: linux-kernel@vger.kernel.org, adilger@turbolinux.com
Subject: fs corruption with invalidate_buffers()
Date: Wed, 6 Dec 2000 03:07:23 +0100	[thread overview]
Message-ID: <20001206030723.A1136@gondor.com> (raw)

Some days ago I saw filesystem corruptions while testing the ext2fs online
resize patches by Andreas Dilger. First I thought that the online resizing
caused the problems, but further investigations didn't support this.

The latest observation shows that the problem is probably neither ext2 nor
lvm related: 

While resizing the filesystem, invalidate_buffers() is called from the
lvm code. (lvm.c, line 2251, in lvm_do_lv_extend_reduce()) 
If I remove this call, the corruption goes away. But this is probably not
the correct fix, as it can cause problems when reducing the lv size.


For reference, some details of the corruption:
	- I reproduced it with kernels between 2.4.0-test9 
	  and 2.4.0-test12-pre5
	- It is easily reproducible immediately after rebooting, but goes
	  away after some uptime (perhaps simply related to the amount of
  	  unused memory)
	- example script follows (attention: absolute device names 
	  like /dev/vg1/test3 hardcoded!)

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

umount /dev/vg1/test3
lvremove -f /dev/vg1/test3
lvcreate -n test3 -L 100M vg1
mke2fs -b 1024 /dev/vg1/test3
ext2prepare -v /dev/vg1/test3 50G
mount /dev/vg1/test3 /mnt/test3

( sleep 20; echo resize1; e2fsadm -L+90M /dev/vg1/test3; echo resize1 done ;
 sleep 10; echo resize2; e2fsadm -L+90M /dev/vg1/test3; echo resize2 done ) &
echo copy1
cp -a /mnt/test/linux /mnt/test3/linux
echo copy1 done
echo copy2
cp -a /mnt/test3/linux /mnt/test3/linux2
echo copy2 done
---------------------------------------------------

/mnt/test/linux contains (surprise) a linux source, but I don't think 
the contents are too important :-). The sleep values are tuned in a way that
leads to the following sequence:

copy1, resize1, resize1 done, copy1 done,
copy2, resize2, resize2 done, copy2 done

After that, the first copy is corrupted in memory only (and is ok after
rebooting), and the second copy is corrupted in memory and on disk. The 
corrupted files contain parts of other files or binary stuff that may come
from directory entries.

I guess that invalidate_buffers somehow marks the buffers that contain
the first copy as free, but the second cp still uses them to copy the
files again. I don't understand the source well enough to find out
how it happens.

Jan

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

             reply	other threads:[~2000-12-06  2:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-06  2:07 Jan Niehusmann [this message]
2000-12-07 19:05 ` fs corruption with invalidate_buffers() Jan Niehusmann
2000-12-07 21:30   ` [PATCH] " Jan Niehusmann
2000-12-07 22:03     ` Udo A. Steinberg
2000-12-07 22:26       ` Alexander Viro
2000-12-07 23:37         ` Jan Niehusmann
2000-12-22  0:03         ` Jan Niehusmann
2000-12-22  0:37           ` Linus Torvalds
2000-12-22  0:48             ` Jan Niehusmann
2000-12-22  1:01               ` Linus Torvalds
2000-12-22  1:49                 ` Jan Niehusmann
2000-12-22  1:56             ` Alexander Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001206030723.A1136@gondor.com \
    --to=jan@gondor.com \
    --cc=adilger@turbolinux.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox