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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux