SSD: `badblocks` / `e2fsck -c` vs reallocated/remapped sectors
The badblocks utility allows one to find bad blocks on a device, and e2fsck -c allows one to add such bad blocks to the bad block inode so that they will not be used for actual data. But for SSD, it is known that bad sectors are normally reallocated (remapped) transparently by the drive (however, only when a write occurs). So, does it make any sense to use badblocks / e2fsck -c on a SSD?
I suppose that
badblocksalone can make sense to get information on the health of the SSD, e.g. by considering the total number of bad blocks (I don’t know whethersmartctlfrom smartmontools can do the same thing… perhaps with a long testsmartctl -t long, but I haven’t seen any clear documentation);- it should be discouraged to use
e2fsck -c(which adds bad blocks to the bad block inode), because due to the possible reallocation, the associated numbers (logical addresses?) may become obsolete.
But there isn’t any warning about the case of SSD in the man pages of these utilities. So I’m wondering…
Hard drives also remap failing sectors on writes, and have done so for decades; this isn’t specific to SSDs. The main wrinkle with badblocks and SSDs compared to hard drives is the amount of wear that writing an entire drive entails (but even that’s not necessarily significant).
This remapping (which doesn’t affect externally-visible block identifiers) means that using badblocks to avoid writing to a block is useless — when a bad block is encountered, it’s actually better to write to it, so that the drive can remap it if necessary. And using badblocks to identify blocks which can’t be read is also not particularly useful; if the data is important, it’s better to use a tool such as ddrescue to try to recover it, and if the data isn’t important, it’s better to overwrite the block so that the drive can remap it if necessary.
The drives’ own tests can be used to identify bad blocks; for that, the best option is the offline test, since that is what updates the most error tracking fields (and thus checks for the most errors). If you run that periodically and look for non-zero “offline uncorrectable” sector counts, you should get the same result as running badblocks. (Run smartctl -a and look at the fields which have “Offline” in their “Updated” column.)
In any case on modern drives, if the drive gets bad enough that its remapping can’t cope and thus excluding blocks from a file system would be useful, then it’s time to recycle it.
See also the Arch wiki for a discussion of badblocks v. remapping. badblocks can be used to force identification of bad blocks by the drive firmware, but I suspect that a more targeted approach (at least when writing) would be preferable on an SSD.