Intro
The Linux NILFS2 filesystem takes continuous "images" of the whole filesystem at regular intervals.
(driven by how much data is written within a specific timespan - you can therefore end up with nothing for several hours and dozens of such "images" within a second).
The creation of such "images" is continuous - old "images" are discarded only once a certain threshold of available free space (set by you) is reached.
I kept on mentioning "image" to avoid conflicts with the nilfs terminology where a "checkpoint" is an image which can be deleted by the filesystem once it needs additional free space and a "snapshot" is still exactly the same thing but which will be kept at any cost, forever, and ever, until you get rid of it (you HAVE to get rid of it to free up space).
As a "normal" enduser the main disadvantages of using NILFS2 are:
- on notebooks there will be a hotspot of CPU&SSD activity (battery consumption) when the threshold of free disk space is reached and the garbage collector kicks in to search&delete old unused "checkpoints"
- "df -h" will report for the device formatted with nilfs2 the space used by the "live" system + the one used by all the existing checkpoints/snapshots (to know how much space you are really using at least you have to run "nilfs-clean" to get rid of all old checkpoints).
The filesystem is quite fast on an SSD (but isn't ultra-fastest-top-of-the-charts-in-any-synthetic-benchmark and no human being will probably notice if the I/O is "only" 250 instead of 300MB/s when using the OS with an SSD under normal conditions).
Due to its nature using it on an HDD (instead of SSD) is most probably not a great idea.
An additional no-go is for heavy write-ops: nobody that does A LOT OF WRITES should use NILFS2.
NILFS2 is therefore good to host your rootFS/webdir/scriptdir/logdir/etc... .
Forcing it to have to deal with a lot of write-ops would bring it out of context and would deliver you absolutely terrible performance => when doing video editing, hosting on it any kind of DB data files, etc... use the plain ext4 or any other kind of specialized fs.
All NILFS2-parameters (for example how often the "checkpoints" should be taken, how much it should stress the system etc...) are all set in the config file "/etc/nilfs_cleanerd.conf".
Example - undelete/restore any previous file state on a nilfs2-filesystem
Prerequisite: your filesystem is formatted with NILFS2.
(all commands execute immediately - no data search nor reconstruction is involved as the old data is ALWAYS fully available)
- List all your available checkpoints:
lscp
CNO DATE TIME MODE FLG NBLKINC ICNT
...
734449 2015-10-06 22:23:36 cp - 165 719741
734450 2015-10-06 22:23:36 cp - 146 719741
734451 2015-10-06 22:23:36 cp - 296 719742
734452 2015-10-06 22:23:40 cp - 61 719741
734453 2015-10-06 22:23:46 cp - 64 719741
734454 2015-10-06 22:23:48 cp - 36 719741
734455 2015-10-06 22:23:48 cp - 176 719741
734456 2015-10-06 22:23:48 cp - 190 719741
734457 2015-10-06 22:23:48 cp - 35 719741
734458 2015-10-06 22:23:48 cp - 43 719741
734459 2015-10-06 22:23:51 cp - 299 719741
734460 2015-10-06 22:23:52 cp - 130 719741
734461 2015-10-06 22:23:57 cp - 289 719741
734462 2015-10-06 22:24:05 cp - 116 719741
734463 2015-10-06 22:24:05 cp - 172 719741
734464 2015-10-06 22:24:05 cp - 46 719741
734465 2015-10-06 22:24:07 cp - 259 719741
... - Identify the time when you think that you still had the file that you just deleted or modified or overwrote and choose any checkpoint ("cp") that exists for that timeframe => in this example I'll choose the checkpoint 734456.
- Convert that checkpoint to a snapshot:
chcp ss 734456 - Doublecheck that the checkpoint ("cp") has now become a snapshot ("ss"):
lscp | grep 734456
734456 2015-10-06 22:23:48 ss - 190 719741 - Mount that particular snapshot that you have just created (in my case the device that is formatted with nilfs2 is "/dev/sda3"):
mount -t nilfs2 -r -o cp=734456 /dev/sda3 /mnt/my_old_state_directory/ - You now have under "/mnt/my_old_state_directory" the whole "image" of how the whole fileystem /dev/sda3 used to look like on 2015-10-06 22:23:48.
Therefore, now read or copy from "/mnt/my_old_state_directory/" the files that you deleted/overwrote by mistake. - Now that you're done and have recovered your data, unmount the snapshot and get rid of it:
- umount /mnt/my_old_state_directory
- Convert the snapshot back to a checkpoint (so that it will be deleted the next time that the garbage collector runs):
chcp cp 734456 - doublecheck:
lscp | grep 734456
734456 2015-10-06 22:23:48 cp - 190 719741
- Great, isn't it?!