9

I have a USB flash drive usb 3, the reading speed is much more than the writing speed. Let's say that 99% of the flash memory is already full with zeros, and I would like to fill it with zeros until 100%, by overwriting all the memory flash with zeros dd if=/dev/zero of=/dev/FLASH.

This process is going to be long, and it will minimize the life expectancy of the flash drive.

I thought, maybe it would be much quicker to check which areas are non-zero, and overwrite only those non-zertos areas with zeros?

Are there anyways of doing this? If it is interesting, I would need all this for security reasons.

Improve this question
5
  • Does the device have a file system on it? And files? Mainly, though, if this is a one-time affair, then dd if=/dev/zero of=/dev/FLASH would be a heck of a lot faster than writing a program to read the drive one block at a time, comparing it to zeros, and rewriting it if it is. Commented Sep 16, 2018 at 16:55
  • dd if=/dev/zero of=/dev/FLASH is not secure enough for legal/compliance purposes, if that is a concern readmoar on secure erase. Commented Sep 16, 2018 at 17:22
  • who do you need to be secure from? what sort of budget does the attacker have? writing zeros to a flash drive may only hide the data. Commented Sep 16, 2018 at 20:45
  • @RonJohn imagine that there is no file system. I want to be 100% that there are only zeros on the flash drive, regardless of whether there is a file system there or not. Commented Sep 17, 2018 at 14:51
  • @Jasen filling the flash drive with zeros I consider sufficient in my circumstances. Commented Sep 17, 2018 at 14:51

1 Answer 1

Reset to default
11

Security reasons aside, let's do it. We can (ab)use GNU ddrescue.

To detect sectors of zeros --generate-mode is useful.

When ddrescue is invoked with the --generate-mode option it operates in "generate mode", which is different from the default "rescue mode". That is, if you use the --generate-mode option, ddrescue does not rescue anything. It only tries to generate a mapfile for later use.

[…]

ddrescue can in some cases generate an approximate mapfile, from infile and the (partial) copy in outfile, that is almost as good as an exact mapfile. It makes this by simply assuming that sectors containing all zeros were not rescued.

[…]

ddrescue --generate-mode infile outfile mapfile

(source)

Let's pretend your device is outfile from previous ddrescue run. We cannot use it as infile (because ddrescue refuses to work when infile and outfile are the same file), we need a dummy one, /dev/zero will do. We should know the physical sector size of your device and use it with -b option. This command may help:

lsblk -o NAME,PHY-SEC /dev/FLASH

Here I assume it's 512.

ddrescue -b 512 --generate-mode /dev/zero /dev/FLASH flash.map

Now flash.map describes every sector either as non-tried (?) or as finished (+), depending on whether it was full of zeros or not. The next step is to fill non-zero sectors with zeros; --fill-mode is perfect for this job:

When ddrescue is invoked with the --fill-mode option it operates in "fill mode", which is different from the default "rescue mode". That is, if you use the --fill-mode option, ddrescue does not rescue anything. It only fills with data read from infile the blocks of outfile whose status character from mapfile coincides with one of the type characters specified as argument to the --fill-mode option.

(source)

We must use the same -b value as with --generate-mode, additionally --force to overwrite the output device. This is the command:

ddrescue -b 512 --force --fill-mode=+ /dev/zero /dev/FLASH flash.map

This time /dev/zero is not just a dummy argument, it's the actual source of data (zeros) written to the device.

Now /dev/FLASH is filled with zeros. Note there may be buffers you need to flush before you physically disconnect the device (useful links: 1, 2, 3).

Improve this answer
1
  • 2
    While it's slightly off this particular topic, it's worth noting that an interesting use for ddrescue's fill-mode in the context of data recovery is to fill blocks defined as bad sectors (fill-mode=-) with zeros after making a copy of files from the image, then make another copy of the files and do a binary comparison of the two sets of files. Any files that don't match had at least some portion in a bad sector (and this will be partially corrupt). Commented Jan 24, 2020 at 2:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.