Messages in this thread | | | Date | Fri, 27 Aug 1999 12:15:08 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [PATCH] robust ext2fs against failure |
| |
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/
| |