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