All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave <dave-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
To: NILFS Users mailing list
	<users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org>,
	jeromepoulin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: Nilfs features
Date: Tue, 02 Jun 2009 12:31:24 +0400	[thread overview]
Message-ID: <4A24E35C.6040209@0bits.com> (raw)
In-Reply-To: <debc30fc0905292044r311a2842j53832195d0ef88bd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 05/30/09 07:44, Jérôme Poulin wrote:
>     checkpointing before installing (which may by default create a
>     snapshot), and then i'd restart the constant checkpointing after i'd
>     finished the install/restore. Please note, i am not comparing nilfs to
> 
>     zfs, but zfs doesn't have constant cp (i think) but does have the
> 
>     feature i mention, i.e you take snapshots when needed (perhaps via a
>     cron job daily, monthly, weekly)
> 
> I just want to give my though on this one, keeping checkpoints as-is 
> seems ideal to me, in this case you have a very granular way to go back 
> in time, however, what you say is right, when installing a new software 
> for example, it's nice to have a way to get back to it, I guess in this 
> case you would just convert the last checkpoint to snapshot before the 
> installation so you have a time mark of where to rollback (and of course 
> have a steady state which won't go away during the installation), right?

Yes correct. Imagine you're installing a fresh OS on a nilfs formatted 
disk. You'd have 1000+ interemediate checkpoints which would be of no 
use. Temporary suspension until the OS is installed is a real life 
use-case. Your filesystem is in 2 states, either no OS or a full OS state.

Cheers
D

  parent reply	other threads:[~2009-06-02  8:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-30  3:44 Nilfs features Jérôme Poulin
     [not found] ` <debc30fc0905292044r311a2842j53832195d0ef88bd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-02  8:31   ` Dave [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-05-25  9:46 Dave
     [not found] ` <4A1A68E6.50905-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
2009-05-25 23:20   ` Ryusuke Konishi
     [not found]     ` <20090526.082051.100027806.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-05-26  4:54       ` Dave
2009-05-31 16:20       ` Ryusuke Konishi
     [not found]         ` <20090601.012057.21016829.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-02  8:21           ` Dave
     [not found]             ` <4A24E100.8040204-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
2009-06-02  9:23               ` Ryusuke Konishi

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=4A24E35C.6040209@0bits.com \
    --to=dave-/hcunnzdxf0avxtiumwx3w@public.gmane.org \
    --cc=jeromepoulin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
    /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.