Introduction
Introduction Statistics Contact Development Disclaimer Help
Title: Linux NILFS file system: automatic continuous snapshots
Author: Solène
Date: 05 October 2022
Tags: linux filesystem nilfs
Description: In this article, I present the Linux file system NILFS and
its automatic continuous snapshoting system.
# Introduction
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.
NILFS project official website
Wikipedia page about NILFS
# NILFS concepts
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.
# Garbage collection
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.
# How to find the current size of your data set
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).
```shell
lscp | awk 'END { print $(NF-1)*4096/1024/1024/1024 }'
```
This number is the current size of what you have on the partition.
# Create a checkpoint / snapshot
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`.
# How to recover files after a big mistake
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:
```shell
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`.
# Going further
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
You are viewing proxied material from dataswamp.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.