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.

  • 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 Dec 17 '20 at 20:26
  • 1
    Related: [Zero filling (vs one-filling) drives: convention or practical reason?](https://superuser.com/q/1403394/432690) – Kamil Maciorowski Dec 17 '20 at 20:40
  • 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 Dec 17 '20 at 21:23
  • Another one: [Can I emulate TRIM by writing all zeros?](https://superuser.com/q/1242000/432690) Answers there also mention writing all ones. – Kamil Maciorowski Dec 17 '20 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. – DrMoishe Pippik Dec 17 '20 at 22:59
  • My concern is that I tend to write a lot of small files to my drives. Since the program->erase behavior is one-way, and the drive does not support TRIM, this implies that anything I do in the future is going to write to a page with random data on it that must be carried along, since the drive doesn't know it's "empty." But now it has to write that random data, which forces a second erase/program if anything extends into that later (in comparison with what if it were already erased and ready to be written). I don't think the drive's smart enough to remap zeros, either. Is there a better way? –  Dec 19 '20 at 03:20

1 Answers1

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.
bitinerant
  • 720
  • 4
  • 10
  • `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/sdx` and dispense with `dd` entirely – roaima Dec 17 '20 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' – bitinerant Dec 17 '20 at 20:32
  • @bitinerant Preferring left-to-right is not an argument against sole `tr` because you can do this: `/dev/sdx`. [I myself prefer left-to-right too](https://superuser.com/a/1335355/432690). – Kamil Maciorowski Dec 17 '20 at 20:38
  • 1
    Writing ones is a waste of time because it is not equivalent to erasure. The FTL knows the difference. – sawdust Dec 17 '20 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? –  Dec 20 '20 at 04:08
  • *"Why is it not the same?"* -- An LBA that was written has physical NAND mapped for it and retains data. An erased block would not be mapped to any LBAs. Apples versus oranges. – sawdust Feb 03 '21 at 00:26
  • I would recommend adding some `bs=8M` or so to `dd`, to write in bigger chunks at once. This will improve speed and may minimise write operations. – Golar Ramblar May 28 '21 at 22:02