On Aug 26, 2008 20:25 -0400, Theodore Ts'o wrote: > On Tue, Aug 26, 2008 at 03:27:43PM -0600, Andreas Dilger wrote: > > I mean that this is for "e2fsck -fn". In that case the filesystem isn't > > changed, and is often completely clean except the superblock counters. > > Until we have block-device freeze ioctl widely available (or convince > > users to use LVM), the best we can do is quiesce Lustre IO without > > unmounting the filesystem. > > Ah, I see. So the main thing that you are trying to achieve with the > patch is avoid the non-zero exit from fsck, right? Yes, the non-zero exit is the main issue. > I guess I'm really not that happy with letting the filesystem getting > marked as "valid" if the user refuses to fix the free blocks/inode > count summary when the -n flag isn't getting set. And technically, if > the summary statistics are wrong, the filesystem is not actually > valid, which is what an exit code of 4, right? Sure, but the summary statistics are _always_ wrong these days. I even think there was even a hack somewhere to e2fsck that you wrote to fixes up the summaries silently when e2fsck was always reporting errors after we turned off the superblock updates... > It seems like the much more "correct" solution, which would actually > be more code, but would also be useful when a user wants to check a > filesystem without actually changing *anything*, including running the > journal, would be to create an I/O manager which reads in the journal > into memory, and creates a "override map" data structure such that > when e2fsck tries to read from a block which is in the journal, that > the (read-only) I/O manager read the block in the journal instead of > from the disk. (Of course it will need to respect the revoke records, > too!) I don't think this is the issue at all. It isn't that the journal has the right summary values either, otherwise waiting 1 commit interval would be enough. The issue is that the kernel NEVER updates the summaries by itself, so the effort to replay the journal in memory would be cool, but wouldn't help at all. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
