I just read through the documentation, and didn’t see any mention (in particular, on the mount options page) of wear leveling. btrfs makes an effort to use SSDs well; how does bcachefs fare in this respect?
You’re right, there isn’t any special effort put towards wear leveling, but the bcache FAQ (NOT bcachefs mind you, but the same should be applicable) mentions this:
#I thought SSDs wore out quickly if you did regular writes to them?
For older SSDs, that was true. Newer SSDs will recognize that a given block is getting heavy writes and will actually swap a heavily written block with a more lightly written block (moving the data transparently and using internal pointers to keep track of the move). This is called “wear leveling” and its use can take a drive whose individual blocks might have tens of thousands of writes before failure and produce an SSD that can support up to millions of writes in a given location by moving data around underneath. Also, keep in mind that unlike (most) standard filesystems that treat SSDs as random access devices that can take any number of writes of any size, bcache understands the write issues in SSDs and tunes its write algorithms to minimize the number of erasures needed. As a side note, what we think of as ‘‘write’’ performance problems on SSDs are largely ‘‘erase’’ performance problems.
bcache is inherently designed to be an ssd cache that sits in front of slower bigger disks. Bcachefs is an extension of this into it’s own filesystem. iirc the words of the bcache creator were: ‘we’ve implemented 80% of a filesystem here, might as well go the rest of the way’. So how much it thrashes a disk is based on what position you give it in the architecture. The caching ssds are going to be used heavily, taking advantage of their fast random access to manage all random accesses, while sequential operations generally go to the slower disk that’s set as the background device. The background disks will tend to be accessed less.
So yeah, it’s based on what kind of disk and position in the bcache, and what caching options you enable. If you want to look into it further, bcache is fs agnostic, so if you can find some tests that have been done for bcache enabled for classic linux filesystems, like ext4 and xfs, that include hardware degradation info, you’ll probably end up with similar usage and hardware wear with the actual bcachefs.
I just read through the documentation, and didn’t see any mention (in particular, on the mount options page) of wear leveling. btrfs makes an effort to use SSDs well; how does bcachefs fare in this respect?
You’re right, there isn’t any special effort put towards wear leveling, but the bcache FAQ (NOT bcachefs mind you, but the same should be applicable) mentions this:
Thank you for finding that!
bcache is inherently designed to be an ssd cache that sits in front of slower bigger disks. Bcachefs is an extension of this into it’s own filesystem. iirc the words of the bcache creator were: ‘we’ve implemented 80% of a filesystem here, might as well go the rest of the way’. So how much it thrashes a disk is based on what position you give it in the architecture. The caching ssds are going to be used heavily, taking advantage of their fast random access to manage all random accesses, while sequential operations generally go to the slower disk that’s set as the background device. The background disks will tend to be accessed less.
So yeah, it’s based on what kind of disk and position in the bcache, and what caching options you enable. If you want to look into it further, bcache is fs agnostic, so if you can find some tests that have been done for bcache enabled for classic linux filesystems, like ext4 and xfs, that include hardware degradation info, you’ll probably end up with similar usage and hardware wear with the actual bcachefs.