newbie question

Can nilfs "roll back" to a previous state of the file system?

For example, at some time = T(N), I have a file system in a known good state. So I check point it before taking a risky action. Then I take a risky action which leads me to the file system state at T(N+1).

Sometimes, my risky action will be fine and I'll want to continue on. Other times, my risky action will result in a polluted, useless collection of data which I would like to discard.

I understand that at time T(N+1) nilfs will allow me to create a checkpoint of T(N) which can be mounted read-only. What I'm asking is if nilfs can discard the state at T(N+1) and "roll back" to the state at T(N) as though T(N+1) had never happened.

Can nilfs do this kind of "roll back"?

--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Sorry to say, but this is the first point in the TODO List:
Checkpoint rollback
See http://www.nilfs.org/en/current_status.html

However, I wonder if this has been worked on being the first point, I guess it should not be hard to do, isn't that what NILFS does on boot after an unclean shutdown?

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

The "roll back" feature is one of our todo items, and not yet supported. At present, nilfs needs user's "copy back" operation to roll back the state at T(N).

I think offline rollback is feasible, but I don't know whether it's true of online rollback because the online rollback needs to discard memory states of some sort or instead ensure consistency for the processes which reside in the namespace of nilfs. This may be done in the same manner as file removal, but I don't know yet.

Cheers,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Is this something that could be accelerated by a suitable application of money?

--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi, Richard

At Thu, 27 May 2010 10:40:41 -0700,

I may not understand your question, but technically speaking it is possible to support roll back feature.
It's just a matter of work force to do as far as I think.

Still, there are some concerns about what the "roll back" sould be.

For instance, if you just want to restore from a specific snapshot you took, you can simply read-only mount the snapshot and copy the contents you want to restore. That is done without any filesystem level roll back support.

Or you want to undone what you did in filesystem, you may be able to delete log and set proper super block. That is tricky, but possible without filesystem level support if it's not mounted.

The hard one is live "roll back", I think, which undone the things on mounted filesystem, or maybe at the boot time by specifying a checkpoint.

In any cases, there should be some utility programs to achieve the functionalities above even it doesn't require any filesystem modifications.

thanks,

regards,

Jiro SEKIBA <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Yes, but the copying requires a significant amount of time that I'm trying to avoid.

I start with a known good file system. I snapshot it. I take some speculative action. And then, based on the result of the speculative action, I either want to create a new snapshot and continue on from there, or I want to "roll back" to the snapshot as though the speculative action had never taken place.

Effectively, I want to start with known good data and then "try something". If the trial succeeds, then I have a new good state. But if it fails, then my entire sub tree is polluted and needs to be replaced or rolled back before I can try something else.

This is akin to a parser with 1 item lookahead or to an AI search tree of depth 1. That is, I'm looking for a cheap backtracking mechanism.

My first strategy involved rsync'ing a subtree elsewhere in the file system as my snapshotting mechanism and then using rsync to replace my current subtree when I needed to "roll back". This costs two large copies and the copies take as much or more time than my transforms do. This means that the copies are the most expensive thing my system does.

My second strategy has been to use LVM snapshots. The cost of rolling back is effectively zero, but I have a small problem in that snapshots can't be snapshotted, (that is, no recursion). Instead, when the speculative action is successful, I either need to copy the successful data back to the original device or I need to repeat the speculative action on the original device, either of which are slow operations comparable to copying my entire subtree again.

What I really want is the ability to make a snapshot, take my speculative action, and then pick which one I want to keep moving forward, without needing to copy all of the data.

If I'm understanding nilfs2 semantics, then it's trivial to discard the snapshot but discarding the most recent state of the file system requires a long copy in user space. I would expect that "roll back" would allow me to simply discard everything that has happened in the file system after a particular snapshot, (permanently and with no mechanism for recovery), returning the file system to that snapshot's state with read-write ability, and would do so significantly faster than copying my entire file system.

It this is true, then I'd like to see it in one of the utility programs.

For my application, it would be sufficient to "roll back" while the system was unmounted, or to somehow mark the portions to be discarded and then remount at the checkpoint I want to keep.

It seems to me that there's not really any conflict about what might be provided, but more a question of the degree to which guarantees are kept during the process.

"Rolling back" is a clearly desirable feature. The declarations should be made using one of the utility programs. Doing so on an unmounted file system is a win over not doing it at all. And doing it on a mounted file system is a win over doing it on an unmounted file system.

--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I don't know nilfs2 internals, but it occurs to me that a "forward" or "leap frog" mechanism might work too.

That is, if a file system is in a state at time T(0), and is in another state at time T(1), then what I'm looking for is the ability to return to a read-write file system with state T(0).

One way to do that might be to "roll back" from state T(1), thereby discarding state T(1). But another way to accomplish this might be to surgically construct a state T(2) which occurs after T(1) and was identical to T(0), leaving T(1) available as a read-only snapshot.

We do this in source control. Rather than backing out a particular change to your source tree, many source control systems require you to commit a reverse diff. This creates a new revision, but a new revision which is identical to an earlier revision which has the apparent affect of removing a change.

I don't know if this would be any easier, but it's a thought.

--rich
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html