On Tue, Feb 24, 2015 at 8:11 AM, Todd Goodman <t...@bonedaddy.net> wrote: > > Can you explain why a log-based filesystem like f2fs would have any > impact on wear leveling? > > As I understand it, wear leveling (and bad block replacement) occurs on > the SSD itself (in the Flash Translation Layer probably.) >
Well, if the device has a really dumb firmware there is nothing you can do to prevent it from wearing itself out. However, log-based filesystems and f2fs in particular are designed to make this very unlikely in practice. Log-based filesystems never overwrite data in place. Instead all changes are appended into empty space, until a large region of the disk is full. Then the filesystem: 1. Allocates a new unused contiguous region of the disk (which was already trimmed). This would be aligned to the erase block size on the underlying SSD. 2. Copies all data that is still in use from the oldest allocated region of the disk to the new region. 3. Trims the entire old region, which was aligned to the erase block size when it was originally allocated. So, the entire space of the disk is written to sequentially, and the head basically eats the tail. Every block on the drive gets written to once before the first block on the drive gets written to twice. The design of the filesystem is basically ideal for flash, and all the firmware has to do is not mess up the perfect order it is handed on a silver platter. You never end up overwriting only part of an erase block in place, and you're trimming very large contiguous regions of the disk at once. Since flash chips don't care about sequential access, if part of the flash starts to fail the firmware just needs to map out those blocks, and as long as it maps an entire erase block at a time you'll get the same performance. Of course, if part of the flash starts to fail the erase count of the remainder of the drive will be identical. so you're going to need a new drive soon. I'd love to see a next-gen filesystem for flash that also takes into account COW snapshotting/reflinks, protection from silent corruption, and some of the RAID-like optimizations possible with btrfs/zfs. Since log-based filesystems are COW by nature I'd think that this would be achievable. The other side of this would be using SSDs as caches for something like btrfs/zfs on disk - something largely possible with zfs today, and perhaps planned for btrfs. -- Rich
