Linux-kernel mailing list archive 1999-34,: Re: [PATCH] robust ext2fs against failure

# Re: [PATCH] robust ext2fs against failure

Theodore Y. Ts'o (tytso@mit.edu)
Fri, 27 Aug 1999 12:15:08 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: jumeaux lists: "Re: strange problems with k2.2.11 / glibc 2.1 / xterm (xfree86 3.3.4)"
- Previous message: Russell King: "Re: Cache incoherencies"

From: kaz@earth.email.ne.jp
Date: Fri, 27 Aug 1999 16:20:59 +0900 (JST)

Hmm...? I do not think so.

1. 'Makefile' stably exists already.
2. /tmp/tmp99825 is newly created.
2a. Memory inode is allocated for /tmp/tmp99825.
2b. But its correspoding data is garbage and points Makefile
(Perhaps it is rare case..., I agree with you)
3. Crash here.
4. Valid memory inode is lost, garbage disk-inode is left
pointing Makefile.

Huh? The scenario you describe doesn't happen, and doesn't make any
sense.

If Makefile exists and is stable, then its inode and its data blocks are
safely on disk.

When /tmp/tmp99825 is created, it will be created with a new inode and
new datablocks. If its corresponding data blocks is garbage, it will
not affect Makefile. If the inode or indirect blocks are not synced to
disk, they may point at data blocks belonging to Makefile, but it still
won't cause the contents of Makefile to be lost. You said the contents
of Makefile would contain binary garbage. I'm saying that can never
happen, as long as you run e2fsck after a crash --- and the sync patches
don't remove that requirement.

In either case, running e2fsck after the crash will clean up the
problem, and the contents of Makefile will not be lost.

- Ted

-
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/

- Next message: jumeaux lists: "Re: strange problems with k2.2.11 / glibc 2.1 / xterm (xfree86 3.3.4)"
- Previous message: Russell King: "Re: Cache incoherencies"