2

I recently ran the F3Tools on a large USB thumb drive that I purchased. It has a 240 GB FAT32 filesystem (not exFAT or NTFS, actual FAT32) on it, and it's supposed to be 256 GB, so I got slightly suspicious. Turns out it's legit, but now I have a flash drive with random data written to all of its sectors, which is bad for write amplification and speed issues down the road.

Since flash drives erase to 0xFF rather than 0x00, is there a way to overwrite a device or file with 1s rather than zeros? If I use zeros, there'll be the same write amplification issue.

I am using Linux (Ubuntu 18.04), so system tools would be best, but I'll also accept anything that's in the apt-get package store.

6
  • It doesn't change the question, but I'm curious about your statement that random data on the flash drive is "bad for write amplification and speed issues down the road". What do you mean?
    – bitinerant
    Commented Dec 17, 2020 at 20:26
  • 1
  • Your concerns are overblown, and your assumptions incorrect. You cannot simulate a block erase by writing ones. Note that the operation of writing (ones or zeros) requires an erased block.The TRIM operation is intended to help minimize write amplification, but a USB flash drive may not support it.
    – sawdust
    Commented Dec 17, 2020 at 21:23
  • Another one: Can I emulate TRIM by writing all zeros? Answers there also mention writing all ones. Commented Dec 17, 2020 at 21:52
  • Each time a flash drive is written, it uses up a bit of it life... each bit can only be changed a finite number of times. There is no practical reason to write to every cell. Commented Dec 17, 2020 at 22:59

1 Answer 1

1

Run this in a terminal:

cat /dev/zero |tr '\0' '\377' |dd of=/dev/sdx

Notes:

  • Replace sdx with your device name, after being absolutely certain it's the right one. (I like to use gparted to review at all my devices, sizes, etc.)
  • The tr command changes 0x00 (all zeros) to 0xFF (all ones).
  • When this finishes, it will give an error that the drive is full. This is expected.
  • You are probably aware - flash drives have a limited number of write cycles.
7
  • dd with no arguments like this will potentially trigger three reads and four writes for each 4K sector on the SSD. You'd be better with tr '\0' '\377' </dev/zero >/dev/sdx and dispense with dd entirely Commented Dec 17, 2020 at 20:26
  • @roaima - I've used dd for writing to flash drives for dozens of years and never read about this. Do you have any references? Your tr '\0' '\377' </dev/zero and my cat /dev/zero |tr '\0' '\377' are equivalent. I just prefer the left-to-right data flow.
    – bitinerant
    Commented Dec 17, 2020 at 20:32
  • @bitinerant Preferring left-to-right is not an argument against sole tr because you can do this: </dev/zero tr '\0' '\377' >/dev/sdx. I myself prefer left-to-right too. Commented Dec 17, 2020 at 20:38
  • 1
    Writing ones is a waste of time because it is not equivalent to erasure. The FTL knows the difference.
    – sawdust
    Commented Dec 17, 2020 at 21:27
  • Why is it not the same? I'd have thought the FTL would go, "Here's a convenient cell with all the bits erased for me. I don't have to do an erase-and-copy-back!" (I mean, if I erase ALL the bits, it won't matter if there's a logical-to-physical mapping since it guarantees that everything in the user-visible pages is still erased.) Is it at least better than leaving random data, since it can't be TRIMmed?
    – user755592
    Commented Dec 20, 2020 at 4:08

You must log in to answer this question.