From: "Theodore Ts'o" <tytso@mit.edu>
To: "Amit S. Kale" <amitkale@linsyssoft.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
Pavel Machek <pavel@ucw.cz>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
Date: Mon, 25 Jul 2005 08:32:04 -0400 [thread overview]
Message-ID: <20050725123204.GB7925@thunk.org> (raw)
In-Reply-To: <200507251124.43898.amitkale@linsyssoft.com>
On Mon, Jul 25, 2005 at 11:24:43AM +0530, Amit S. Kale wrote:
> On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote:
> > >Maybe you want to put your development machines on ext*2* while doing
> > >this ;-). Or perhaps reiserfs/xfs/something.
> >
> > Or perhaps into at the VFS level, so any fs can benefit from it.
>
> We thought about that. While it's possible to do that, it would need
> hooks into all filesystems etc. Definitely worth trying once we get
> some more basic stuff working for ext3
>
> After all the things that need to be saved at the time of taking a
> checkpoint for any filesystem would be the superblock and inode
> table (or their equivalents). Everything else is automatically taken
> care of.
You are aware of the block-device-level snapshot solutions, right?
They can be more painful to use, although that's mostly a UI issue,
and they have the added advantage that you can safely run e2fsck on
the snapshot image if you want to check the consistency of the
filesystem while it is mounted. (If it is clean, you can then use
tune2fs to reset the max-mount-count and last-checked-time on the
original filesystem image; if it is not clean, you can send e-mail to
the system administrator suggesting that she schedule downtime ASAP
and do a e2fsck on the filesystem image. This is a good thing that a
paranoid sysadmin might schedule via cron every Saturday morning at
3am, for example.)
- Ted
next prev parent reply other threads:[~2005-07-25 12:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-23 6:00 CheckFS: Checkpoints and Block Level Incremental Backup (BLIB) Amit S. Kale
2005-07-23 15:25 ` Theodore Ts'o
2005-07-24 14:23 ` Pavel Machek
2005-07-24 15:14 ` Jan Engelhardt
2005-07-25 5:54 ` Amit S. Kale
2005-07-25 12:32 ` Theodore Ts'o [this message]
2005-07-25 12:52 ` Amit S. Kale
-- strict thread matches above, loose matches on Subject: below --
2005-08-01 7:50 Milind Dumbare
2005-08-01 10:08 ` Theodore Ts'o
2005-08-02 7:05 ` Milind Dumbare
2005-07-22 14:04 Milind Dumbare
2005-07-22 19:54 ` Theodore Ts'o
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=20050725123204.GB7925@thunk.org \
--to=tytso@mit.edu \
--cc=amitkale@linsyssoft.com \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox