Is BTRFS suitable for an HDD?

Ask Fedora Ask in English
1

I want filesystem-level snapshots for my SMR HDD, used mainly as a data backup and archival disk. Is BTRFS suitable for this job? Any alternatives?
I currently use rsync incremental snapshots (on ext4 partition), but BTRFS is more space efficient and covers the whole filesystem.

Edit: this is the HDD in question:

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Blue Mobile (SMR)
Device Model:     WDC WD10SPZX-60Z10T0
Serial Number:    WD-WXQ1AA8ENJ47
LU WWN Device Id: 5 0014ee 65e7e7f1b
Firmware Version: 04.01A04
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
1 Like
2

Yes

zfs. However, since it isn’t supported natively by the kernel it is more work to get it configured.

You can also take lvm snapshots with xfs. I think btrfs is better solution for most use cases though.

1 Like
3

Everyone has their own opinion on that question.

BTRFS is relatively new in the everyday world, and I am still observing. There have been cases where the file system was filled up then even though files were removed and space freed up the nodes were not available for use without running a cleanup process on the btrfs file system.

To me it still seems a little less reliable than ext4, though promising in the long run.

1 Like
4

Is there an objective view on this subject? I forgot to add the drive is unfortunately an SMR drive.

5

You need to perform two steps:

1.) take a read-only snapshot of a subvolume (maybe create a subvolume before)
2.) use btrfs send ... | btrfs receive ... to send the volume to a different location

if you search the internet, you’ll find guides, like to the following:

6

no, because it depends who you ask.
Btrfs is used in OpenSuse and, for example, at Facebook’s data centers for quite a while. If you ask there you will certainly get a different answer from when you ask people who have lost data on Btrfs.

I don’t see why that matters…

7

SMRs are different than normal CMRs disks. See more here

I think the Copy on write nature of BTRFS would be better for such HDD.

1 Like
8

Shingled magnetic recording - Wikipedia says:

“Btrfs had ZBD support added in Linux kernel 5.12, and it already writes mostly sequentially due to the CoW nature.”

SMR drives like to write continuously, and are sensitive to overwriting data, so CoW should be a clear advantage compared to ext4 or xfs.

So, if you really can’t avoid the SMR drive(s), better use Btrfs…

Also, you need backups anyway, so don’t waste too much time worrying about SMR and the filesystem. Once the SMR is dead, your next drive can be CMR again :wink:

9

It came with the laptop and if it wasn’t me checking SMART status I wouldn’t have noticed it’s a SMR drive (it also makes sense why this HDD has TRIM). I will switch to BTRFS then, thanks!

1 Like
10

Personally I would never recommend that BTRFS be used on an SMR drive.
There is a major difference in the data storage and any potential faults of btrfs will only be greatly exacerbated by the SMR technology.
I use only HDDs with CMR tech. They are higher priced, but speed and durability are greatly improved.

11

Can you please elaborate? I chose BTRFS for its compression, copy on write which is mostly sequential, and fs level snapshots.

The drive is probably firmware managed, I can hear the actuator arm moving around sometimes after backup (even if the disk activity LED is off).

12

SMR → Shingled Magnetic Recording

This shows that the data is in overlapping (shingled) layers, and writing to a lower layer requires removing the data from the overlapping layers, writing the lower layer of data then restoring the overlapping layers of data. It seems the top layer is written first, then lower layers added as needed.

Even for the most reliable of file systems it involves an excessive amount of time for this type of writing and each layer has a chance of data corruption as it is read then rewritten. The more data on the drive, the more this type of writing is required. The more layers used the less space available in each layer.

For example, if the tech uses 3 layers, then for a 1TB drive there is only about 330 GB available in each layer. Or for 4 layers then each layer would be only 1/4 the total drive space.

Yes, that is supposed to be handled by the drive firmware, but even the manufacturers only recommend those drives for home use and sell drives with CMR tech for NAS or data center use.

13

Thanks for the info. I’m using the disk as a backup and the amount of data I have isn’t large. The disk has been in service for 3 years and it’s SMART status haven’t reported uncorrectable errors, so I’m probably fine using it.

Edit: I switched back to ext4, rsync incremental snapshots should be enough for my use case.

(Ironically this was supposed to be a boot disk, I can’t imagine how slow something like Windows would be on such disk, plus the extreme wear due to write amplification).