Nilfs features

Nilfs features

[Dave]

Hi,

I converted (backup/restore) my home directory onto nilfs2 to test it in 
anger  (yes i know the caveats about it corrupting all my data, etc, but 
i'm willing to restore when required).

When restoring the data onto a nilfs2 filesystem there really is no 
requirement to have the checkpointing running as you have a good copy 
from your tar, cpio archive that you are restoring from. So is there a 
way to temporarily suspend checkpointing with a command and then restart 
it after the restore has completed ? I think this would be useful also 
for when  you want to have a 'privacy' mode (like firefox/mozilla) where 
you can suspend checkpointing, start some confidential work, email, 
browsing etc, and then restart checkpointing and roll back to the 
previous state.

In addition to this there doesn't seem to be a way to delete a range of 
checkpoints. When i did my restore from my archive, i generated 700+ 
useless checkpoints which i had to delete one by one (in a script). It 
would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to 
delete a checkpoint range, a start to end.

Also it seems for home directories, a 5 second checkpointing seems 
exessive. In 14hrs i have 10,000 checkpoints (even when seemingly idle 
with mozilla page refreshes, dovecot index files updates  for email, etc).


home:~$ uptime
  13:35:09 up 14:29,  7 users,  load average: 0.85, 1.76, 2.07
home:~$ lscp|tail
                10342  2009-05-25 13:34:31   cp    i       6698     323163
                10343  2009-05-25 13:34:36   cp    -       6761     323163
                10344  2009-05-25 13:34:41   cp    i       6702     323163
                10345  2009-05-25 13:34:45   cp    -         29     323163
                10346  2009-05-25 13:34:46   cp    i       6679     323163
                10347  2009-05-25 13:34:51   cp    i       6669     323163
                10348  2009-05-25 13:34:56   cp    i       6675     323163
                10349  2009-05-25 13:35:01   cp    i       6676     323163
                10350  2009-05-25 13:35:06   cp    i       6649     323163
                10351  2009-05-25 13:35:11   cp    i       6679     323163


It would also be nice to change the cp/clean interval without editing 
the conf file, perhaps during the nite we can had different checkpoint 
intervals and during work a smaller cp interval.


Finally instead of having 5 commands, it'd be nice to have once command 
with different options (like zfs). So instead have

. nilfs checkpoint
. nilfs snapshot
. nilfs remove
. nilfs list
. nilfs suspend
. nilfs restart
etc...

All seems to be working fine so far, so take this as constructive comments.

Cheers
Dave

Re: Nilfs features

[Ryusuke Konishi]

Hi,
On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> Hi,
> 
> I converted (backup/restore) my home directory onto nilfs2 to test it in 
> anger  (yes i know the caveats about it corrupting all my data, etc, but 
> i'm willing to restore when required).

What happened to you ?
Anyway, thanks for your interest in nilfs.
(yeah, I'm trying my best, but I keenly feel it's really tough to keep
the reliability of the filesystem.  so, please remember the caveat.)
 
> When restoring the data onto a nilfs2 filesystem there really is no 
> requirement to have the checkpointing running as you have a good copy 
> from your tar, cpio archive that you are restoring from.

Yes, definitely.

> So is there a way to temporarily suspend checkpointing with a
> command and then restart it after the restore has completed ? I
> think this would be useful also for when you want to have a
> 'privacy' mode (like firefox/mozilla) where you can suspend
> checkpointing, start some confidential work, email, browsing etc,
> and then restart checkpointing and roll back to the previous state.

Is your demand rollback feature or some kind of silent (or invalid by
default) checkpointing, or both ?

The checkpointing is essential for nilfs, every write on nilfs
requires creating a checkpoint by its nature.  But I think it's
possible to make them inaccessible by default.

Rollback is worth considering.  Yes, I agree.  it actually makes the
recovery of filesystem state smarter.

It even could be a first step toward realization of the remote
replication (as discussed before in this mailing list).

> In addition to this there doesn't seem to be a way to delete a range of 
> checkpoints. When i did my restore from my archive, i generated 700+ 
> useless checkpoints which i had to delete one by one (in a script). It 
> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to 
> delete a checkpoint range, a start to end.

Okay, I'll take in this in some form.

> Also it seems for home directories, a 5 second checkpointing seems 
> exessive. In 14hrs i have 10,000 checkpoints (even when seemingly idle 
> with mozilla page refreshes, dovecot index files updates  for email, etc).
>
> home:~$ uptime
>   13:35:09 up 14:29,  7 users,  load average: 0.85, 1.76, 2.07
> home:~$ lscp|tail
>                 10342  2009-05-25 13:34:31   cp    i       6698     323163
>                 10343  2009-05-25 13:34:36   cp    -       6761     323163
>                 10344  2009-05-25 13:34:41   cp    i       6702     323163
>                 10345  2009-05-25 13:34:45   cp    -         29     323163
>                 10346  2009-05-25 13:34:46   cp    i       6679     323163
>                 10347  2009-05-25 13:34:51   cp    i       6669     323163
>                 10348  2009-05-25 13:34:56   cp    i       6675     323163
>                 10349  2009-05-25 13:35:01   cp    i       6676     323163
>                 10350  2009-05-25 13:35:06   cp    i       6649     323163
>                 10351  2009-05-25 13:35:11   cp    i       6679     323163
> 
> 
> It would also be nice to change the cp/clean interval without editing 
> the conf file, perhaps during the nite we can had different checkpoint 
> intervals and during work a smaller cp interval.

Checkpoint creation is essential to nilfs writes, so this seems to be
difficult without introducing some kind of invisible checkpoint.
(checkpoint removal is much easier, but I understood what you want
 slightly differs from such external )

I think it needs care because the feature partially invalidate what
the nilfs stands for.  Maybe 5 seconds checkpoining should be remained
as default.  But some flexiblity might well be allowed as you pointed
out.

Supporting method changing cleaning interval without editing the conf
file, sounds reasonable (yes, sorry for inconvenience).
 
> Finally instead of having 5 commands, it'd be nice to have once command 
> with different options (like zfs). So instead have
> 
> . nilfs checkpoint
> . nilfs snapshot
> . nilfs remove
> . nilfs list
> . nilfs suspend
> . nilfs restart
> etc...

Yeah, I agree reorganizing commands into one 'nilfs' command is
preferable.  Well, I'll add this to the todo items on the site.

I think it would be nice if the old commands are available through
symbolic links to this unified command according to user's
predilection.
 
> All seems to be working fine so far, so take this as constructive comments.
>
> Cheers
> Dave

Thank you for many productive comments!

 
Regards,
Ryusuke Konishi

Re: Nilfs features

[Dave]

Ryusuke Konishi wrote:
>
>> I converted (backup/restore) my home directory onto nilfs2 to test it in
>> anger  (yes i know the caveats about it corrupting all my data, etc, but
>> i'm willing to restore when required).
>
> What happened to you ?
> Anyway, thanks for your interest in nilfs.
> (yeah, I'm trying my best, but I keenly feel it's really tough to keep
> the reliability of the filesystem.  so, please remember the caveat.)

Yes, understood very well, but you also you underestimate your code ;-)
Please keep up the good work. The free world has been waiting for this 
kind of filesystem for a while.

>> So is there a way to temporarily suspend checkpointing with a
>> command and then restart it after the restore has completed ? I
>> think this would be useful also for when you want to have a
>> 'privacy' mode (like firefox/mozilla) where you can suspend
>> checkpointing, start some confidential work, email, browsing etc,
>> and then restart checkpointing and roll back to the previous state.
>
> Is your demand rollback feature or some kind of silent (or invalid by
> default) checkpointing, or both ?

No, not demanding anything. Requesting it as a feature. While your 
design has a very crucial use-case of constant checkpointing, there is 
also a use-case to *suspend* checkpointing (or enable it on demand 
only). As mentioned in my previous example, when restoring to a 
filesystem, or even installing new software, it is extremely unlikely 
that you would want a to go back to a point *inbetween* the time you 
started the install/restore to the time it completed. Say for example 
you are installing a new version of Openoffice which installs

   home:/opt/openoffice.org$ find . ! -type d |wc -l
       4100

4000 odd files. For sure if the software didn't work, crashed, was 
buggy, i would go back completely to the pre-install state and would 
never need any intervening checkpoint. In this case i would suspend 
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)


> The checkpointing is essential for nilfs, every write on nilfs
> requires creating a checkpoint by its nature.  But I think it's
> possible to make them inaccessible by default.
>
> Rollback is worth considering.  Yes, I agree.  it actually makes the
> recovery of filesystem state smarter.
>
> It even could be a first step toward realization of the remote
> replication (as discussed before in this mailing list).

Yes, after i posted, i went back on the mailing list and seen the 
request already. Sorry for requesting the feature again.


> I think it needs care because the feature partially invalidate what
> the nilfs stands for.  Maybe 5 seconds checkpoining should be remained
> as default.  But some flexiblity might well be allowed as you pointed
> out.

Agreed, but it wouldn't invalidate what nilfs stood for, it would 
enhance it, but it is your code, so it's your right to decide and i 
respect that.

> Supporting method changing cleaning interval without editing the conf
> file, sounds reasonable (yes, sorry for inconvenience).

No need to apologize.

>> Finally instead of having 5 commands, it'd be nice to have once command
>> with different options (like zfs). So instead have
>>
>> . nilfs checkpoint
>> . nilfs snapshot
>> . nilfs remove
>> . nilfs list
>> . nilfs suspend
>> . nilfs restart
>> etc...
>
> Yeah, I agree reorganizing commands into one 'nilfs' command is
> preferable.  Well, I'll add this to the todo items on the site.

Thanks (my /usr/bin directory seems to be growing exponentially).

> I think it would be nice if the old commands are available through
> symbolic links to this unified command according to user's
> predilection.

Agreed, but why have 5 commands and 5 manpages when you can have 1 of 
each ;-). I think users will get used to it and eventually you can 
delete the symlinks.

Thanks for your responses.
D

Re: Nilfs features

[Ryusuke Konishi]

Hi,
On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
> Hi,
> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> > In addition to this there doesn't seem to be a way to delete a range of 
> > checkpoints. When i did my restore from my archive, i generated 700+ 
> > useless checkpoints which i had to delete one by one (in a script). It 
> > would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to 
> > delete a checkpoint range, a start to end.
> 
> Okay, I'll take in this in some form.

For the moment, I've added this feature and pushed it into the git
tree.

(Instead of '1-100', '-100', or '10..', I took notation like '1..100',
 '..100', or '10..' respectively, according to the git tool)

If you would like to try it soon, please see

 http://www.nilfs.org/git/

for download/build information.

I'll include it in the next release of the utility package.

Cheers,
Ryusuke Konishi

Re: Nilfs features

[Dave]

On 05/31/09 20:20, Ryusuke Konishi wrote:
> Hi,
> On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
>> Hi,
>> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
>>> In addition to this there doesn't seem to be a way to delete a range of 
>>> checkpoints. When i did my restore from my archive, i generated 700+ 
>>> useless checkpoints which i had to delete one by one (in a script). It 
>>> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to 
>>> delete a checkpoint range, a start to end.
>> Okay, I'll take in this in some form.
> 
> For the moment, I've added this feature and pushed it into the git
> tree.
> 
> (Instead of '1-100', '-100', or '10..', I took notation like '1..100',
>  '..100', or '10..' respectively, according to the git tool)
> 
> If you would like to try it soon, please see
> 
>  http://www.nilfs.org/git/
> 
> for download/build information.
> 
> I'll include it in the next release of the utility package.
> 

Hi Ryusuke,

I've tried this and it seems to work perfectly. Thanks for the quick 
feature addition.

It seems that i still have to wait for cleanerd to kick in to reclaim 
the space even though i clearly cannot get to a checkpoint i've just 
deleted. I believe we should reclaim immediately (but perhaps this is 
harder to implement)...


bash-3.2# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb2              39G  9.0G   28G  25% /home
bash-3.2# cp /shared/1gb .
bash-3.2# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb2              39G   10G   27G  28% /home
bash-3.2# lscp | tail
               155133  2009-06-02 12:12:27   cp    i       6662     253255
               155134  2009-06-02 12:12:29   cp    -         35     253255
               155135  2009-06-02 12:12:32   cp    i       6622     253255
               155136  2009-06-02 12:12:37   cp    i       6587     253255
               155137  2009-06-02 12:12:42   cp    i       6654     253255
               155138  2009-06-02 12:12:47   cp    i       6744     253255
               155139  2009-06-02 12:12:52   cp    i       6524     253255
               155140  2009-06-02 12:12:57   cp    i       6762     253255
               155141  2009-06-02 12:13:02   cp    i       6670     253255
               155142  2009-06-02 12:13:07   cp    -       6748     253255
bash-3.2# rm 1gb
bash-3.2# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb2              39G   10G   27G  28% /home
bash-3.2# lscp|tail
               155151  2009-06-02 12:13:29   cp    -         35     253188
               155152  2009-06-02 12:13:35   cp    -        237     253229
               155153  2009-06-02 12:13:37   cp    -       6334     253238
               155154  2009-06-02 12:13:42   cp    -       8380     253255
               155155  2009-06-02 12:13:47   cp    i       7987     253255
               155156  2009-06-02 12:13:52   cp    i       3743     253255
               155157  2009-06-02 12:13:57   cp    i       8092     253255
               155158  2009-06-02 12:14:02   cp    i       7991     253255
               155159  2009-06-02 12:14:07   cp    i       7986     253255
               155160  2009-06-02 12:14:12   cp    -       9129     253254
bash-3.2# rmcp ..155160
bash-3.2# lscp|tail
                  CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
               155161  2009-06-02 12:14:17   cp    i       6839     253254
               155162  2009-06-02 12:14:22   cp    i       7012     253254
               155163  2009-06-02 12:14:27   cp    -       6886     253255
               155164  2009-06-02 12:14:29   cp    -         51     253254
               155165  2009-06-02 12:14:32   cp    i       6737     253254
               155166  2009-06-02 12:14:37   cp    i       2618     253254
bash-3.2# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb2              39G   10G   27G  28% /home



much appreciated.
Dave

Re: Nilfs features

[Ryusuke Konishi]

Hi,
On Tue, 02 Jun 2009 12:21:20 +0400, Dave wrote:
> On 05/31/09 20:20, Ryusuke Konishi wrote:
> > Hi,
> > On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
> >> Hi,
> >> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> >>> In addition to this there doesn't seem to be a way to delete a range of 
> >>> checkpoints. When i did my restore from my archive, i generated 700+ 
> >>> useless checkpoints which i had to delete one by one (in a script). It 
> >>> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to 
> >>> delete a checkpoint range, a start to end.
> >> Okay, I'll take in this in some form.
> > 
> > For the moment, I've added this feature and pushed it into the git
> > tree.
> > 
> > (Instead of '1-100', '-100', or '10..', I took notation like '1..100',
> >  '..100', or '10..' respectively, according to the git tool)
> > 
> > If you would like to try it soon, please see
> > 
> >  http://www.nilfs.org/git/
> > 
> > for download/build information.
> > 
> > I'll include it in the next release of the utility package.
> > 
> 
> Hi Ryusuke,
> 
> I've tried this and it seems to work perfectly. Thanks for the quick 
> feature addition.
> 
> It seems that i still have to wait for cleanerd to kick in to reclaim 
> the space even though i clearly cannot get to a checkpoint i've just 
> deleted. I believe we should reclaim immediately (but perhaps this is 
> harder to implement)...
 
Yes, checkpoint removal by rmcp does not mean reclamation; operation
of the cleanerd is necessary to that end.

Well, I thought the (plain) checkpoints are equivalent to deleted
ones.  But the checkpoint removal makes a differece in that deleted
checkpoints become unprotected by the protection period.

Hmm, indeed we need some change on the cleanerd.
At least the cleanerd should be notified about the removal and
revaluate the need of reclamation.

Thanks you for feedback.


Regards,
Ryusuke Konishi

 
> bash-3.2# df -h .
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2              39G  9.0G   28G  25% /home
> bash-3.2# cp /shared/1gb .
> bash-3.2# df -h .
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2              39G   10G   27G  28% /home
> bash-3.2# lscp | tail
>                155133  2009-06-02 12:12:27   cp    i       6662     253255
>                155134  2009-06-02 12:12:29   cp    -         35     253255
>                155135  2009-06-02 12:12:32   cp    i       6622     253255
>                155136  2009-06-02 12:12:37   cp    i       6587     253255
>                155137  2009-06-02 12:12:42   cp    i       6654     253255
>                155138  2009-06-02 12:12:47   cp    i       6744     253255
>                155139  2009-06-02 12:12:52   cp    i       6524     253255
>                155140  2009-06-02 12:12:57   cp    i       6762     253255
>                155141  2009-06-02 12:13:02   cp    i       6670     253255
>                155142  2009-06-02 12:13:07   cp    -       6748     253255
> bash-3.2# rm 1gb
> bash-3.2# df -h .
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2              39G   10G   27G  28% /home
> bash-3.2# lscp|tail
>                155151  2009-06-02 12:13:29   cp    -         35     253188
>                155152  2009-06-02 12:13:35   cp    -        237     253229
>                155153  2009-06-02 12:13:37   cp    -       6334     253238
>                155154  2009-06-02 12:13:42   cp    -       8380     253255
>                155155  2009-06-02 12:13:47   cp    i       7987     253255
>                155156  2009-06-02 12:13:52   cp    i       3743     253255
>                155157  2009-06-02 12:13:57   cp    i       8092     253255
>                155158  2009-06-02 12:14:02   cp    i       7991     253255
>                155159  2009-06-02 12:14:07   cp    i       7986     253255
>                155160  2009-06-02 12:14:12   cp    -       9129     253254
> bash-3.2# rmcp ..155160
> bash-3.2# lscp|tail
>                   CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
>                155161  2009-06-02 12:14:17   cp    i       6839     253254
>                155162  2009-06-02 12:14:22   cp    i       7012     253254
>                155163  2009-06-02 12:14:27   cp    -       6886     253255
>                155164  2009-06-02 12:14:29   cp    -         51     253254
>                155165  2009-06-02 12:14:32   cp    i       6737     253254
>                155166  2009-06-02 12:14:37   cp    i       2618     253254
> bash-3.2# df -h .
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb2              39G   10G   27G  28% /home
> 
> 
> 
> much appreciated.
> Dave

Re: Nilfs features

[Jérôme Poulin]

[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]

>
> No, not demanding anything. Requesting it as a feature. While your
> design has a very crucial use-case of constant checkpointing, there is
>
> also a use-case to *suspend* checkpointing (or enable it on demand
> only). As mentioned in my previous example, when restoring to a
> filesystem, or even installing new software, it is extremely unlikely
> that you would want a to go back to a point *inbetween* the time you
>
> started the install/restore to the time it completed. Say for example
> you are installing a new version of Openoffice which installs
>
> home:/opt/openoffice.org$ find . ! -type d |wc -l
>
> 4100
>
> 4000 odd files. For sure if the software didn't work, crashed, was
> buggy, i would go back completely to the pre-install state and would
> never need any intervening checkpoint. In this case i would suspend
>
> 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?

[-- Attachment #1.2: Type: text/html, Size: 1987 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: Nilfs features

[Dave]

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