-- Leo's gemini proxy
-- Connecting to perso.pw:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Author: Solène
Date: 05 October 2022
Tags: linux filesystem nilfs
Today, I'll share about a special Linux file system that I really enjoy. It's called NILFS and has been imported into Linux in 2009, so it's not really a new player, despite being stable and used in production it never got popular.
In this file system, there is a unique system of continuous checkpoint creation. A checkpoint is a snapshot of your system at a given point in time, but it can be deleted automatically if some disk space must be reclaimed. A checkpoint can be transformed into a snapshot that will never be removed.
This mechanism works very well for workstations or file servers on which redundancy is nonexistent, and on which backups are done every day/weeks which give room for unrecoverable mistakes.
As NILFS is a Copy-On-Write file system (CoW), which mean when you make a change to a file, the original chunk on the disk isn't modified but a new chunk is created with the new content, this play well with making an history of the files.
From my experience, it performs very well on SSD devices on a desktop system, even during heavy I/O operation.
The continuous checkpoint creation system may be very confusing, so I'll explain how to learn about this mechanism and how to tame it.
The concept of a garbage collector may appear given for most people, but if it doesn't speak to you, let me give a quick explanation. In computer science, a garbage collector is a task that will look at unused memory and make it available again.
On NILFS, as a checkpoint is created every few seconds, used data is never freed and one would run out of disk pretty quickly. But here is the `nilfs_cleanerd` program, the garbage collector, that will look at the oldest checkpoint and delete them to reclaim the disk space under certain condition. Its default strategy is trying to keep checkpoints as long as possible, until it needs to make some room to avoid issues, it may not suit a workload creating a lot of files and that's why it can be tuned very precisely. For most desktop users, the defaults should work fine.
The garbage collector is automatically started on a volume upon mount. You can use the command `nilfs-clean` to control that daemon, reload its configuration, stop it etc...
When you delete a file on a NILFS file system, it doesn't free up any disk space because it's still available in a previous checkpoint, you need to wait for the according checkpoints to be removed to have some space freed.
As the output of `df` for a NILFS filesystem will give you the real data used on the disk for your data AND the snapshots/checkpoints, it can't be used to know how much free disk is available/used.
In order to figure the current disk usage (without accounting older checkpoints/snapshots), we will use the command lscp to look at the number of blocks contained in the most recent checkpoint. On Linux, a block is 4096 bytes, we can then turn the total in bytes into gigabytes by dividing three time by 1024 (bytes -> kilobytes -> megabytes -> gigabytes).
lscp | awk 'END { print $(NF-1)*4096/1024/1024/1024 }'
This number is the current size of what you have on the partition.
It's possible to create a snapshot of your current system state using the command `mkcp`.
mkcp --snapshot
Or you can turn a checkpoint into a snapshot using the command chcp.
chcp ss /dev/sda1 28579
The opposite operation (snapshot to checkpoint) can be done using `chcp cp`.
Let's say you deleted an important in-progress work, you don't have any backup and no way to retrieve it, fortunately you are using NILFS and a checkpoint was created every few seconds, so the files are still there and at reach!
The first step is to pause the garbage collector to avoid losing the files: `nilfs-clean --suspend`. After this, we can think slowly about the next steps without having to worry.
The next step is to list the checkpoints using the command `lscp` and look at the date/time in which the files still existed and preferably in their latest version, so the best is to get just before the deletion.
Then, we can mount the checkpoint (let's say number 12345 for the example) on a different directory using the following command:
mount -t nilfs2 -r -o cp=12345 /dev/sda1 /mnt
If it went fine, you should be able to browse the data in `/mnt` to recover your files.
Once you finished recovering your files, umount `/mnt` and resume the garbage collector with `nilfs-clean --resume`.
Here is a list of extra pieces you may want to read to learn more about nilfs2:
nilfs_cleanerd and nilfs_cleanerd.conf man pages to tune the garbage collector
man pages for lscp / mkcp / rmcp / chcp to manage snapshots and checkpoints manually
-- Response ended
-- Page fetched on Mon May 6 03:13:51 2024