4

I'm trying to understand the effects of wear-leveling on fragmentation in SSD. To be more specific, when the SSD controller decides to allocate a noncontiguous block to a file because of wear-leveling, the file will be fragmented.

Now, will this fragmentation be reflected in the PBA part of the addressing, or the LBA? As an example, say File A occupies Logical Block Addresses (LBA) 10,11,12, (corresponding to PBA 300, 301, 302). The file is updated and needs an additional block. Now because of wear-leveling, lets say the next available contiguous block (PBA 303) has a high Program/Erase count, and the controller selects BPA block 500 that is mapped to LBA 600. will the controller now update LBA 13 to point to BPA 500?(and therefore no fragmentation from the point of view of the OS)? or will the file have LBA's 10, 11, 12 and 600, therefore resulting in the LBA being fragmented? (and the host OS viewing the file as fragmented)

If the file is fragmented in terms of PBA, but the mapping is done in a way where the LBA is always contiguous, then for the host OS, the file will always be contiguous.

However, I keep reading that, for example, in the case of file recovery, that one of the problems in recovering files from SSDs is that they are heavily fragmented. If that's the case, then that must mean that the fragmentation is reflected in the LBA itself.

I would really appreciate if someone can shed more light on how fragmentation actually takes place in view of BPA and LBA. Thanks.

Improve this question
0

1 Answer 1

Reset to default
3

AFAIK, wear leveling is completely transparent to the OS. The OS will request blocks 10, 11, 12, and 13, and the SSD will give it LBA 10, 11, 12, and 13. (See ultrasawblade's comment below)

SSDs are usually heavily fragmented because there is little to no benefit of defragmenting them. Requesting PBA 10, 11, 12, and 13 might actually be slower than requesting PBA 10, 11, 12, and 600 because PBA 600 can be fetched in parallel to PBA 10, 11, and 12 if the latter 3 are all on the same chip and must be fetched in sequence. Wear leveling might actually intentionally map these blocks to different chips and create fragmentation.

LBAs fragment naturally with creation/deletion of files.

The end result is that the LBAs are fragmented, and then the LBA -> PBA mapping is also fragmenting the PBAs to ensure the disk wears evenly. Since the LBAs are fragmented, file recovery is difficult.

So, both LBA and PBA are both independently fragmented, but for different reasons. If the OS keeps the filesystem completely defragmented, then it would actually be defragmented (as far as LBAs are concerned and regardless of wear leveling and PBA fragmentation) and easy to recover files. Most OSes don't keep the filesystem defragmented if they know it's on an SSD because it results in additional wear on the drive with little to no performance benefit.

Improve this answer
8
  • 1
    The OS only sees the LBAs (unless it's raw flash), so it doesn't know or care what's going on with the SSD drives LBA->PBA mapping. SSDs don't understand filesystems so they don't know or care about the OSs file-to-LBA mapping, they only care about their own internal LBA->PBA mapping. The only way for the OS to tell the SSD anything about how it is actually using it is via TRIM.
    – LawrenceC
    May 15, 2014 at 22:16
  • @"Darth Android" So, the LBA fragmentation, which is the fragmentation you can see from the OS point of view has nothing to do with wear-leveling? So in a data recovery type scenario, wear leveling would only be a factor to how fragmented files are if the FTL is corrupted?
    – OSM10
    May 15, 2014 at 22:53
  • @OSM10 Correct! And because the OS makes no attempt to defragment the LBA's, even the LBA view of an SSD is also highly fragmented. Data recovery from SSDs is just painful however you look at it. :(
    – Darth Android
    May 17, 2014 at 18:44
  • @DarthAndroid Thanks. I'm trying to find references on how filesystems manage/implement block allocations when dealing with SSDs, to get a better understanding of this, but can't seem to find any resource.
    – OSM10
    May 20, 2014 at 21:24
  • @OSM10 Filesystems don't do anything different when it comes to block allocations when dealing with SSDs. In fact, outside of the TRIM command, filesystems are not even aware what kind of media that are running on (HDD, SSD, file container, etc.)
    – Darth Android
    May 20, 2014 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .