Ability to discard all changes after a point in time?

Ability to discard all changes after a point in time?

[dexen deVries]

Hi,


recently I was searching for a way to discard all changes after a certain 
point in time -- that is, to rollback filesystem state to a particular 
checkpoint. I couldn't find a way, is there any?

If not, I'd like to request such functionality. Preferrably selectable at 
mount time, via an argument to mount (or the `rootflags' kernel parameter).

Something along the lines `rollbackto=<checkpoint-number>'. 

The desired effect is to set the indicated checkpoint as the latest one, so all 
subsequent changes to filesystem are discarded.


What are your thoughts on that?


Regards,
-- 
dexen deVries

``One can't proceed from the informal to the formal by formal means.''
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[Ryusuke Konishi]

Hi,
On Fri, 27 May 2011 08:28:28 +0200, dexen deVries wrote:
> Hi,
> 
> 
> recently I was searching for a way to discard all changes after a certain 
> point in time -- that is, to rollback filesystem state to a particular 
> checkpoint. I couldn't find a way, is there any?
> 
> If not, I'd like to request such functionality. Preferrably selectable at 
> mount time, via an argument to mount (or the `rootflags' kernel parameter).
> 
> Something along the lines `rollbackto=<checkpoint-number>'. 
> 
> The desired effect is to set the indicated checkpoint as the latest one, so all 
> subsequent changes to filesystem are discarded.
> 
> 
> What are your thoughts on that?

The feature is indeed one of todo items, and I just have been
considering the topic for upcoming LinuxCon Japan.

At present, I made a patchset which can revert only one fully deleted
regular file without duplicating data blocks. (This work derives your
post titled "It is not possible to restore file from a mounted
snapshot using a hardlink" and the successive reflink topic.)


The challenge in the rollback (or revert) feature is to handle
lifetime of each disk block, which is maintained for garbage
collection.  (a disk address table, which we call DAT file, preserves
this metadata).

The mount-time whole checkpoint reversion, that is to say rollback,
seems rather difficult than this.  In my estimation, it would take too
long time to rewrite whole DAT file.

But, yes, I think this feature is one of priorities, and have plan to
take time for it.

Thanks,
Ryusuke Konishi


> Regards,
> -- 
> dexen deVries
> 
> ``One can't proceed from the informal to the formal by formal means.''
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[Mateusz Jan Przybylski]

Hi Ryusuke,

On Friday 27 of May 2011 09:34:34 you wrote:
> The feature is indeed one of todo items, and I just have been
> considering the topic for upcoming LinuxCon Japan.
> 
> At present, I made a patchset which can revert only one fully deleted
> regular file without duplicating data blocks. (This work derives your
> post titled "It is not possible to restore file from a mounted
> snapshot using a hardlink" and the successive reflink topic.)
> 
> 
> The challenge in the rollback (or revert) feature is to handle
> lifetime of each disk block, which is maintained for garbage
> collection.  (a disk address table, which we call DAT file, preserves
> this metadata).
> 
> The mount-time whole checkpoint reversion, that is to say rollback,
> seems rather difficult than this.  In my estimation, it would take too
> long time to rewrite whole DAT file.

thanks for prompt reply.

I'm surprised this is that complex. My limited understanding of NILFS2 was 
that the latest complete checkpoint is considered `the current one' during 
mount. The big idea was to irreversibly destroy (by actually overwritting 
relevant metadata) the checkpoints if admin indicated that wish with the 
supposed new `rollbackto=<checkpoint_number>' parameter. Just before the mount 
operation; perhaps even going through the normal rountine for recovery after 
unclean mount.

After that, the latest remaining checkpoint (the one indicated in option) 
would be the current state of the FS. The metadata from that checkpoint would 
be used, and newer metadata from newer checkpoints would simply be 
inaccessible to the driver. No new checkpoint would be created in that case, 
unlike the action of `rmcp' command.

How far am I here from the actual workings of the filesystem?


meta: oops, sent reply directly to Ryusuke again. Sorry~


Regards
--
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[Ryusuke Konishi]

Hi,
On Fri, 27 May 2011 09:44:51 +0200, Mateusz Jan Przybylski wrote:
> Hi Ryusuke,
> 
> On Friday 27 of May 2011 09:34:34 you wrote:
>> The feature is indeed one of todo items, and I just have been
>> considering the topic for upcoming LinuxCon Japan.
>> 
>> At present, I made a patchset which can revert only one fully deleted
>> regular file without duplicating data blocks. (This work derives your
>> post titled "It is not possible to restore file from a mounted
>> snapshot using a hardlink" and the successive reflink topic.)
>> 
>> 
>> The challenge in the rollback (or revert) feature is to handle
>> lifetime of each disk block, which is maintained for garbage
>> collection.  (a disk address table, which we call DAT file, preserves
>> this metadata).
>> 
>> The mount-time whole checkpoint reversion, that is to say rollback,
>> seems rather difficult than this.  In my estimation, it would take too
>> long time to rewrite whole DAT file.
> 
> thanks for prompt reply.
> 
> I'm surprised this is that complex. My limited understanding of NILFS2 was 
> that the latest complete checkpoint is considered `the current one' during 
> mount. The big idea was to irreversibly destroy (by actually overwritting 
> relevant metadata) the checkpoints if admin indicated that wish with the 
> supposed new `rollbackto=<checkpoint_number>' parameter. Just before the mount 
> operation; perhaps even going through the normal rountine for recovery after 
> unclean mount.
> 
> After that, the latest remaining checkpoint (the one indicated in option) 
> would be the current state of the FS. The metadata from that checkpoint would
> be used, and newer metadata from newer checkpoints would simply be 
> inaccessible to the driver. No new checkpoint would be created in that case, 
> unlike the action of `rmcp' command.
>
> How far am I here from the actual workings of the filesystem?

Unfortunately, some of the metadata such as the DAT file is global to
the filesystem and does not belong to any checkpoints.  Your thought
is roughly correct, but we also have to care the DAT file as well as
the checkpoint information.  Otherwise, the next garbage collection
will collapse the filesystem.

Regards,
Ryusuke Konishi
 
> meta: oops, sent reply directly to Ryusuke again. Sorry~
> 
> 
> Regards
> --
> dexen deVries
> 
> [[[↓][→]]]
> 
> For example, if the first thing in the file is:
>    <?kzy irefvba="1.0" rapbqvat="ebg13"?>
> an XML parser will recognize that the document is stored in the traditional 
> ROT13 encoding.
> 
> (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[Jiro SEKIBA]

Hi,

At Fri, 27 May 2011 08:28:28 +0200,
dexen deVries wrote:
> 
> Hi,
> 
> 
> recently I was searching for a way to discard all changes after a certain 
> point in time -- that is, to rollback filesystem state to a particular 
> checkpoint. I couldn't find a way, is there any?

I know this is not what you want, but as a partial solution,
timebrowse (http://timebrowse.sourceforge.net/) can restore the files
or directories of NILFS2 checkpoints from nautilus interface.

Of course, this will merely rsync from the checkpoint to current mount point.
Therefore all the history still remain in the log and it may take
unreasonable time if the differences are big.

thanks,

regards,

> If not, I'd like to request such functionality. Preferrably selectable at 
> mount time, via an argument to mount (or the `rootflags' kernel parameter).
> 
> Something along the lines `rollbackto=<checkpoint-number>'. 
> 
> The desired effect is to set the indicated checkpoint as the latest one, so all 
> subsequent changes to filesystem are discarded.
> 
> 
> What are your thoughts on that?
> 
> 
> Regards,
> -- 
> dexen deVries
> 
> ``One can't proceed from the informal to the formal by formal means.''
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


-- 
Jiro SEKIBA <jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[dexen deVries]

Hi Jiro,

On Wednesday 01 of June 2011 14:33:13 you wrote:
> I know this is not what you want, but as a partial solution,
> timebrowse (http://timebrowse.sourceforge.net/) can restore the files
> or directories of NILFS2 checkpoints from nautilus interface.
> 
> Of course, this will merely rsync from the checkpoint to current mount
> point. Therefore all the history still remain in the log and it may take
> unreasonable time if the differences are big.


Thanks, that's a good thing. Btw., is there any KIO slave or application for 
KDE with similar functionality?

My target usecase was: OS is so mis-configured it won't even boot. I wanted to 
pass a parameter to kernel to make it discard some recent changes and go on 
with a slightly older version of files.

Another usecase was: due to bug in older kernel FS had a few recent 
checkpoints corrupted. It's either back files up and re-format the filesystem, 
or roll back a few minutes to an older, correct checkpoint.


Regards,
-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ability to discard all changes after a point in time?

[Jiro SEKIBA]

Hi, dexen

At Wed, 1 Jun 2011 14:41:12 +0200,
dexen deVries wrote:
> 
> Hi Jiro,
> 
> On Wednesday 01 of June 2011 14:33:13 you wrote:
> > I know this is not what you want, but as a partial solution,
> > timebrowse (http://timebrowse.sourceforge.net/) can restore the files
> > or directories of NILFS2 checkpoints from nautilus interface.
> > 
> > Of course, this will merely rsync from the checkpoint to current mount
> > point. Therefore all the history still remain in the log and it may take
> > unreasonable time if the differences are big.
> 
> 
> Thanks, that's a good thing. Btw., is there any KIO slave or application for 
> KDE with similar functionality?

Unfortunately no, or no volunteer yet ;-p.

Timebrowse has two parts, snapshot manager and nautilus add-on.

Snapshot manater keep nilfs checkpoints and alter its to snapshots and
mount its specified mount point.  In later snapshots will be unmount
and sparse or deleted.

While, nautils add-on is completely independent from the manager.
It tries to find nilfs checkpoint mount from /proc/mounts and
list the checkpoint.

So if you want KIO slave or something similar for KDE, you may be able to
utilize the snapshot manager to implement the functionality you want.

> My target usecase was: OS is so mis-configured it won't even boot. I wanted to 
> pass a parameter to kernel to make it discard some recent changes and go on 
> with a slightly older version of files.
> 
> Another usecase was: due to bug in older kernel FS had a few recent 
> checkpoints corrupted. It's either back files up and re-format the filesystem, 
> or roll back a few minutes to an older, correct checkpoint.

If the problem is rather simple, like need to boot correct kernel in
the file system in the log boot loader may help it.
#and pray the log roll forward on boot time.

Current grub2 nilfs module only tries to find kernel from latest log.
However, implementation itself can specify any checkpoint.
The problem is how to specify the checkpoint from standard grub2 interface.
grub2 does not have any parapeter for file system module :(.


regards,

> 
> Regards,
> -- 
> dexen deVries
> 
> [[[↓][→]]]
> 
> For example, if the first thing in the file is:
>    <?kzy irefvba="1.0" rapbqvat="ebg13"?>
> an XML parser will recognize that the document is stored in the traditional 
> ROT13 encoding.
> 
> (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


-- 
Jiro SEKIBA <jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html