2

I create compressed backup images using dd and lzop on a regular basis. In the past I've created a large file beforehand with zeros using head -c xxG /dev/zero > zeros.tmp && rm zeros.tmp (xxG was the empty space available) to clean out deleted files. This saved a lot of time and backup disk space, but it's also highly ineffective since it goes all over the empty space and therefore causes unnecessary wear on SSDs.

Does fstrim also zero blocks with unallocated files? Or will dd return these blocks with their deleted content afterwards? I don't want to compress blocks with unallocated files.

lmoly
  • 407
  • 1
  • 4
  • 12

1 Answers1

2

Data returned on reads after a trim (using fstrim or any other such tool or mount option) depends on the device: some will return random data, some will return unvarying non-zero data, some will return zeroes. You can run hdparm -I on ATA devices to determine which of these options applies: it will show “Deterministic read data after TRIM” for the second, “Deterministic read ZEROs after TRIM” for the third, otherwise the first applies.

For your specific use-case, other tools might be more appropriate; for example, if you’re imagine Ext2/3/4 file systems, e2image -ra will create a backup image containing only the blocks which are in use, and e2image -Qa will create a QCOW2 image containing only the blocks which are in use.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • Would `hdparm -I` also return the deterministic read value on a NVme device or do I need to go a different route there? – lmoly Feb 03 '20 at 10:34
  • I’m not sure, the NVMe specifications for trim don’t match ATA’s... – Stephen Kitt Feb 03 '20 at 10:35
  • 2
    To answer my own question: my Samsung 970 Evo has “Deterministic read ZEROs after TRIM” as TRIM method. After a `fstrim -v /` this effectively results in zeroed blocks as I was able to verify by the compressed backup file size before fstrim and after. – lmoly Feb 16 '20 at 17:59