On Aug 03, 2007  10:19 +0530, Aneesh Kumar K.V wrote:

Andreas Dilger wrote:

quoted

I thought about this also, but in fact for most uses of the undo manager
we want to save the information at the start instead of the end, so it
is possible to undo e.g. a partial e2fsck that crashes before it finishes.
Only with mke2fs (and, I guess tune2fs -U) does the UUID change at the
end.

I am not sure whether saving the information at start is needed. I 
understand that what we are looking for is the case when the application
crashes without doing a io_channel_close. In that case i would say the
user can use the --force option and replay the data from the tdb file.
The UUID could very well be changed on the disk before the application
crashed. So even if we save UUID at the start, there are cases where it
won't match with the disk UUID.

While this is true, I don't think it is harmful to save the UUID at the
start.  The UUID changing is the rare case, so to make this safer saving
the UUID at the start and the end is best.

That actually brings me to another change. I would be moving the block size
recording changes from write_file_system_identity to a separate function 
and will be calling it at the first write.

Definitely, yes.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.