On Aug 01, 2007 13:22 +0530, Aneesh Kumar K.V wrote: > >>Can you let me know a use case where this will fail. > > > >- modify filesystem with undo manager (e.g. inode resize) > >- mount filesystem, make changes, unmount > >- run undoe2fs to overwrite filesystem, corrupting it > > But that won't corrupt it. It will bring the file system back to > the state before inode resize. No, that isn't correct. The changes done to the filesystem while mounted will not be recorded in the undo file. If the undo file can be replayed over the modified filesystem then only the blocks in the undo file will be restored, but none of the other blocks that were modified while the filesystem was mounted. > I understand that we may want to have > > a) Don't replay if file system is mounted > b) Don't replay if UUID doesn't match > > But i guess we should allow a replay if file system got changed afterwards. > Ofcourse the changes will no longer be available after the replay. No this shouldn't be allowed, except in "--force" mode (which would be needed after mke2fs because the UUID and s_mtime would change). For cases like e2fsck the undo might be helpful. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, 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
