>>>>> Vyacheslav Dubeyko writes:
> As I know, checkpointing is a fundamental technique of the NILFS. It
> is possible to imagine checkpointing as an act of final placing of
> file system blocks on disk storage. Another filesystems also writing
> on disk but, usually, without possibility to keep history of file
> system operations and manage by history. Checkpoint in NILFS is
> natural possibility to prevent from file system inconsistency and
> failure by means of Copy-On-Write policy. Of course, checkpoints
> keep duplicates of metadata and data information but obsolete
> checkpoints can be deleted by nilfs_cleanerd. So, from my point of
> view, your approach is trying to overcome the main goal of the NILFS.
Not at all. The idea is to utilize NILFS snapshots to record
consistent states of the chroot environment. So, e. g., having
found that certain software package did break, I can bisect the
filesystem history to find the version of the package which have
introduced the bug.
Using rsync(1) makes this easier, as there's both much less work
to the GC, and it takes less time to perform the changes, so
there are only a few checkpoints to check.
> What about reliability in your approach? Everything can occur during
> operations under tmpfs partition (for example, sudden power off).
Then, the latest operation (# apt-get install something) won't
be effective and will have to be repeated. But the target
chroot environment will still be in a consistent state.
[…]
--
FSF associate member #7257 http://sf-day.org/
--
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
