Messages in this thread | | | Date | Fri, 1 Mar 2002 19:41:55 +0000 | From | "Stephen C. Tweedie" <> | Subject | Re: [OOPS 2.5.5-dj2] ext3 BUG in do_get_write_access() |
| |
Hi,
On Thu, Feb 28, 2002 at 05:19:44PM -0800, Wayne Whitney wrote:
> I managed to generate the oops below on 2.5.5-dj2 by doing the following: > cp -ax / /mnt & > <some delay, don't know if it matters> > tune2fs -L root /dev/hdc5
> tune2fs -L should be safe on a mounted filesystem, non?
Hmmm.
There's a fundamental problem here. Journaling filesystems expect to be in control over when data gets written to the disk. tune2fs is writing to the superblock in the buffer cache directly, and ext3 is really, really paranoid about finding unexpected dirty buffers since they usually imply that we have just violated the filesystem's write ordering expectations.
Clearly in this case something legal has just happened, but it still means that the superblock can get flushed to disk before the filesystem expects it, and this can result in an inconsistency on disk after recovery if we crash just after that flush.
So saying "this is legal" means data corruption, and protecting the fs from such interference (eg. by moving the on-disk superblock representation into the page cache) will prevent tune2fs from working at all: the updated fields will just be overwritten by the filesystem's copy.
In this particular case, I think I'll just have to relax the assertion and cause it to printk instead of BUG()ing, because I don't want to lose the protection of this test entirely.
I'd really like to be able to detect such direct buffered-io "interference" from user-space, though, so that I could preserve the BUG() in cases where ext3 is getting this wrong internally. I'll look at that --- I may be able to achieve it through ext3's existing metadata flags.
Cheers, Stephen - 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/
| |