I would like to ask about the potential of data loss due to wear-leveling on an encrypted partition of a USB stick / SSD disk.

Let's consider this scenario: I create a truecrypt partition on a flash drive (stick/disk) and put there sensitive data. A different non-encrypted ntfs/ext4 partition of the same disk is used for regular exchange of files.

When I view the disk partitions (e.g.with parted, fdisk...etc) so the encrypted partition looks like unused without a file system. The file system pops up after decryption only. The encrypted partition must look like a once written random clutter of free sectors when not mounted.

So the problem - how does the disk itself (its wear-leveling mechanism) tell free sectors from used ones? if I understand the wear-leveling correctly it remaps the physical sectors to logical ones based on the number of writes. If I again copy a big file on my normal partition then free physical sectors from the encrypted partition will be remapped to logical sectors belonging to the normal partition due to low number of writes and used to hold the new file.

I researched this topic a bit but have not found a significant number of posts where people would be complaining about this.

Where are my assumptions wrong?


The disk itself has no notion of what a filesytem may be. The disk knows what internal blocks are used and what are not through some metadata which never exit the disk, and the OS is completely unaware of them.

You are conflating two distinct notions of "free sectors", which occur on distinct machines at distinct levels. The disk itself works over a number of internal "blocks"; using these blocks, the disk maintains a logical view of the disk space as a long sequence of bytes (conventionally split into successive sectors). The disk will internally split the disk space over the blocks, with some redundancy, reordering, dynamic copies and other smart algorithms which together aim at spread wear so as to make failures happen less often; this is the "wear levelling".

The OS only sees the sectors, which are not necessarily of the same size as blocks (indeed, Flash blocks tend to be on the 16 to 64 kB size, while sectors are traditionally 512 bytes), and the wear levelling is hidden to the OS. The OS uses some sectors to encode the filesystem structures, and these structures mark other sectors as "free" or "in use". From the point of view of the OS, a sector is "free" if it does not contain anything interesting anymore (e.g. it was part of a file which has been deleted since); whereas from the point of view of the disk, a block is "free" if it was never written to, or if the wear levelling algorithm already copied its contents to other blocks, and the block can be internally reused.

If a sector has been written to, then the data made it into a SSD block; if the corresponding file is deleted, the sector is "free" from the point of view of the OS (the OS will allow itself to write to that sector the contents of another file), but for the SSD this still is data which has to be preserved -- and preserve it it does.

An enlightening (or not) feature to consider is the TRIM command. This is a SATA command by which the OS may inform the disk that a given range of sectors is considered "free" (by the OS), allowing the disk not to preserve their contents until they are next written to. When the OS has TRIMmed some sectors, reading the sectors directly (from the device, bypassing the filesystem layer) may theoretically return varying data bytes, depending on how the disk manages things internally. "TRIM" is the only way by which "free sectors" from the filesystem, and "unused blocks" from the physical medium, may actually relate to each other. They are otherwise wholly independent notions.

  • thank you, Tom. that's a perfect detailed answer. it's clear - plausible deniability has no chance on flash drives, but the data loss is ruled out due to possible TRIM commands taking place ONLY (if at all) when the partition is encrypted and mounted. – user2433984 Aug 22 '13 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.