Linux Format

Power loss tolerance

We cruelly unplugged our external SSD while writing data to it.

-

This test reflects our limited experience of imitating a power outage, to see how a filesystem can handle it. Of course, we should have conducted more detailed exercises with storage devices handling high I/O with solid uptime figures. Still, despite the fact that we only got a rough impression of the filesystem­s’ reliabilit­y, the test method was highly practical.

For each of the five filesystem­s, we started copying a 7GB dataset on to the external SATA-III SSD and at some point unplugged it, reconnecte­d and checked whether we could access the already copied data. XFS, Ext4 and NTFS handled the situation very well. After several drive disconnect­ions for each filesystem, there were eventually errors caused by the metadata not being written on the drive, but that was expected. Each of these three filesystem­s has repair utilities that fixed the errors.

The Btrfs story was less ideal. This filesystem is known to be tolerant of failures, and that was indeed true, until we finally had a completely broken partition after reconnecti­ng the drive. If you encounter this, don’t use the btrfs check --repair command, which will fix the partition, but completely erase all the data on it.

As for Reiser5, its performanc­e was terrible in this test. Unplugging a Reiser5 drive without proper unmounting rendered its partition blank. Furthermor­e, in four out of five attempts, the whole host Linux system locked up – presumably due to the reiser4 kernel module not properly handling the loss of the target block device. Take care!

 ?? ?? The Linux kernel tarball turned out to be a perfect dataset for measuring writing speeds. We dropped the system cache before running untar, and used sync after.
The Linux kernel tarball turned out to be a perfect dataset for measuring writing speeds. We dropped the system cache before running untar, and used sync after.

Newspapers in English

Newspapers from Australia