From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 2/4] e2fsprogs: Add undoe2fs
Date: Wed, 01 Aug 2007 13:22:30 +0530 [thread overview]
Message-ID: <46B03BBE.1060309@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070801071032.GQ5469@schatzie.adilger.int>
Andreas Dilger wrote:
> On Aug 01, 2007 11:46 +0530, Aneesh Kumar K.V wrote:
>> Andreas Dilger wrote:
>>> On Aug 01, 2007 07:34 +0530, Aneesh Kumar K.V wrote:
>>>> undoe2fs can be used to replay the transaction saved
>>>> in the transaction file using undo I/O Manager
>>> This should save the mtime of the superblock, and only do the undo
>>> step if the filesystem hasn't changed. Otherwise it could seriously
>>> corrupt the filesystem.
>> I am not sure i understand this. The Undo I/O manager tracks all the write
>> happening to the file system and copy the original content of the blocks to
>> the tdb file. Undoe2fs simply copies these blocks back to the file system.
>>
>> That way if you look at undoe2fs it doesn't have any knowledge of the file
>> system at all.
>>
>> 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. 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.
-aneesh
next prev parent reply other threads:[~2007-08-01 7:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-01 2:04 [PATCH 1/4] e2fsprogs: Add undo I/O manager Aneesh Kumar K.V
2007-08-01 2:04 ` Aneesh Kumar K.V
2007-08-01 2:04 ` [PATCH 2/4] e2fsprogs: Add undoe2fs Aneesh Kumar K.V
2007-08-01 2:04 ` Aneesh Kumar K.V
2007-08-01 6:02 ` Andreas Dilger
2007-08-01 6:16 ` Aneesh Kumar K.V
2007-08-01 6:33 ` Kalpak Shah
2007-08-01 7:10 ` Andreas Dilger
2007-08-01 7:52 ` Aneesh Kumar K.V [this message]
2007-08-01 8:27 ` Andreas Dilger
2007-08-01 2:04 ` [PATCH 3/4] e2fsprogs: Make mke2fs use undo I/O manager Aneesh Kumar K.V
2007-08-01 2:04 ` Aneesh Kumar K.V
2007-08-01 6:04 ` Andreas Dilger
2007-08-01 6:14 ` Aneesh Kumar K.V
2007-08-01 7:14 ` Andreas Dilger
2007-08-01 2:04 ` [PATCH 4/4] e2fsprogs: Support for large inode migration Aneesh Kumar K.V
2007-08-01 2:04 ` Aneesh Kumar K.V
-- strict thread matches above, loose matches on Subject: below --
2007-08-01 15:34 e2fsprogs patches Aneesh Kumar K.V
2007-08-01 15:34 ` [PATCH 1/4] e2fsprogs: Add undo I/O manager Aneesh Kumar K.V
2007-08-01 15:34 ` Aneesh Kumar K.V
2007-08-01 15:34 ` [PATCH 2/4] e2fsprogs: Add undoe2fs Aneesh Kumar K.V
2007-08-01 15:34 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B03BBE.1060309@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.