Zeroing the content of a hard drive without destroying the filesystem
mount /dev/your/disk /some/free/mountpoint dd if=/dev/zero of=/some/free/mountpoint/zero bs=512 sync # See edit below rm /some/free/mountpoint/zero umount /some/free/mountpoint
This will do exactly what you asked for: Overwrite all space, that is available to files in the file system, with zeroes.
More complex answer:
- Without nuking the MBR you can't be sure, you don't have an MBR virus
- an empty file system has no value
So I recommend you just nuke the device (i.e. zero the device, including MBR and file system) and then just recreate the partition table and
mkfs.ntfs -f -L LABEL -I
As @Nyos pointed out in the comments, if the NTFS driver does not mount sync (I don't know the defaults), it is a good idea to insert an extra
sync before the
rm. The current version (as of Ubuntu 18.04 fully patched to 2020-05-02) does no delayed block allocated, so the
sync is not strictly necessary, as all allocated blocks will be written out on
umount, but neither do we know the future nor did I read the full source code.
On the same note: If the NTFS driver once gets sparse file support, we might need to use
/dev/urandom instead of
/dev/zero to avoid a (nearly) endless write.
Although this doesn't answer your question at all... nevertheless:
First, it is a really, really bad idea to zero out a disk. That is true for "traditional" disks, and even moreso for solid state disks. Zeroing out a disk is trivial to do (just create a file and fill it, Eugen Rieck gives the exact recipe) but it takes a long time and wears down the disk. Write cycles are not infinite, on any kind of hard disk.
Also, note that you do not even have a guarantee that overwriting actually works as intended. For your purpose, the difference will not be noticeable, but for other purposes (think secure erase of confidential data) the approach is entirely unreliable. That is because you have absolutely no way of knowing what happens when you overwrite something thanks to wear-levelling and reallocation. Drives do a lot of stuff without anyone (including the operating system!) knowing or even having a way of telling, let alone changing. If, for example, a sector has been reallocated because the controller wasn't happy with the number of retries, or the CRC or whatever, you can do whatever you want going forward, you are simply not getting to access that sector any more. Never again. Still, the data, or what's left of it (and you cannot know) stays there, and a potential thief could read it out.
Second, when operating in full paranoia mode, it is a really, really bad idea to keep the filesystem (and MBR) around, especially when the disk is "empty". Other than the filesystem's UUID, you will not lose anything by just creating a new filesystem (which arguably can be a bit of a nuisance in some situations, but that's easy to fix, too). You do, however, gain the certainity that there's nothing left in places where you don't expect it (MBR, for instance).
Third, it is a bad idea to zero out and reuse an "empty" filesystem which is in reality not empty at all. It's bad in terms of performance when you can instead just create a new FS (without stale change journal entries, invisible items, forgotten streams, attributes, fragmented MFTs...) from scratch. Not only is recreating everything from scratch much more secure, it's also much faster, and it will likely result in better overall performance going forward.
Most devices have a dedicated secure erase or "factory reset" option (which is the same) which is supported by the accompanying management tool, or with some other tool via a standard ATA command. The drive will use the most efficient, least destructive method (some drives indeed overwrite the complete disk in lack of truly supporting the feature, but most will just dump the encryption or bit scrambling key, which works almost instantly regardless of disk size).
hdparm which is available on pretty much every Linux distro out of the box has an option
--security-erase for that exact purpose.
This will give you a disk "as if just bought" with the exception of having been used for a while. It will do so in the fastest (within what's technically possible) and least disk-murdering way. Following that, partition it and create a filesystem, done.