[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070801082743.GS5469@schatzie.adilger.int>
Date: Wed, 1 Aug 2007 03:27:43 -0500
From: Andreas Dilger <adilger@...sterfs.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc: tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/4] e2fsprogs: Add undoe2fs
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists