3 ms·
>also known as breaking compatibility with all previous filesystems.... Pretty much every filesystem in use has the ability to mark sections of a drive as bad
by ChrisLomont 4y ago
>also known as breaking compatibility with all previous filesystems....
Pretty much every filesystem in use has the ability to mark sections of a drive as bad and unusable. Pretty much every SSD in use has more blocks than it shows to the filesystem. It would not be hard to leverage both of these and likely implement this paper with zero change to the filesystem or drivers, and the SSD can remap bad sectors to the end of the space on the drive, allowing bootloaders and the like to work exactly as they do now.
- wtallis 4y agoRemapping bad sectors to the end of the drive doesn't solve much. For starters, GPT actually expects the end of the drive to be usable, so we'd need to introduce a new partition table format or make the drive an active participant in updating the partition table. But more importantly, you cannot simply hand-wave away the challenges of having NAND erase blocks that are huge compared to both NAND page sizes and the allocation units used by host software. If you make a drive that is at first glance "compatible" with existing software and filesystems but behind the scenes has to do eg. 24MB read-modify-write cycles for any size of host write, the drive may be much simpler than current SSDs but will be dead within a week or two at most (and painfully slow until then).
- ChrisLomont 4y agoSSDs already do all you just listed behind the scenes. The FTL is already mapping such things behind the scenes so filesystems don't have to implement it. As the paper mentions, changes to these cycles lengthens the lifetime. The filesystem at the os level won't change.