Some devices are improperly detected on Linux as being rotational (ie: hard-drive with spinning disks) when, in fact, the device is an SSD (flash type) device. mkfs.btrfs checks:

/sys/block/DEVICE/queue/rotational

where DEVICE is a block device (sda, sdb, etc...) and if the contents of that file is 1, then mkfs.btrfs considers that the device is rotational and disables SSD features.

In case mkfs.btrfs disables SSD features but you are certain that the device is an SSD, you can simply:

echo 0 >/sys/block/DEVICE/queue/rotational

where DEVICE is the block device, in order to make the kernel treat the device as a non-spinning disk.

After that, you can issue mkfs.btrfs with your favourite options and mkfs.btrfs will detect the device as an SSD.

btrfs supports snapshotting at the volume level such that individual files cannot be backed up but rather a snapshot of the entire volume has to be taken. Subvolumes typically exist on the same filesystem as a sub-directory and in order to take a snapshot, a snapshot directory has to first be created using the command line:

btrfs subvolume create /mnt/volume/.snapshots

where:

• /mnt/volume is the path where the btrfs filesystem is mounted,
• /mnt/volume/.snapshots is the path where the subvolume will be created

After which a snapshot of the volume can be created, for example, by issuing:

btrfs subvolume snapshot -r /mnt/volume /mnt/volume/.snapshots/20250811

where:

• -r stands for read-only,
• /mnt/volume is the path where the btrfs filesystem is mounted,
• /mnt/volume/.snapshots/20250811 is the subdirectory that will store the snapshot

Snapshots are instantaneous because btrfs maintains a link between inodes such that the snapshot file represents a careful set of links rather than a complete copy of a file.

Restoring a file does not require any special command but rather copying the file using regular tools should be sufficient. For example to restore /mnt/volume/writeup.docx from the snapshot folder /mnt/volume/.snapshots/20250811, simply copying it over is sufficient:

cp /mnt/volume/.snapshots/20250811/writeup.docx /mnt/volume/

To delete the volume-level snapshot after that, issue:

btrfs subvolume delete /mnt/volume/.snapshots/20250811

which should delete the entire folder /mnt/volume/.snapshots/20250811

It is one of our personal paradigms to use SQLite instead of other database solutions because SQLite is a very portable database that does not require a centralized setup such that migrating from one machine to another is just a matter of copying over files without having to ensure that a database system can be setup in the first place.

On the other hand, we've talked about contextualizing storage by usage patterns and choose to use different drives and filesystems for various purposes such that in one instance we have stored Docker data on a separate drive formatted with the BTRFS filesystem. The Docker data contains many SQLite databases, some of larger size but not containing any irreplaceable data, but the kind of data that must be accessed fast.

The problem is that BTRFS has two major features that both make it great but at the same bad for storing SQLite databases:

• default copy-on-write
• compression

Compression can be turned off at mount time by specifying compression=no and the main problem with compression is that it keeps the databases busy, which results in errors along the line of the database being locked. This is because due to compression, access to the files is not purely atomic, ie: when the application closes the database, the database might still remain open while compression goes on in the background. This makes concurrent accesses to the database, even by the same application a nightmare with intermittent failures.

Copy-on-Write (CoW) on the other hand would have it that once a database is updated, then the whole file will have to be rewritten. That is, even if a database is opened up and just a flag is set with, say, some UPDATE SQL command, then when the database is released, the whole database flatfile must be rewritten. This re-writing generates some crazy amount of I/O, and for databases that are larger, just CoW alone can bring the whole filesystem to a crawl. CoW can be turned off the same way but taking any snapshots after that will turn on CoW again. Similarly, iff. the filesystem has been running for a while, CoW cannot be disabled for the files that have been created whilst it was turned on, except for recopying over all the data.

With that said, in case errors are perceived along the lines of databases being busy, concurrency issues arise with locks not holding atomically and other atomicity errors, and iff. the underlying filesystem is BTRFS, then be aware that these issues are known and the best option we have found is to use a different filesystem to work around these issues.