I use Victoria HDD for Windows.

Use Test & Repair, select range and select Write test. This will overwrite the data. Although this Write test is only available when you remove all partitions on the HDD.

man dd

seek=N
skip N obs-sized blocks at start of output

count=N
copy only N input blocks

Yes, dd allows you to skip portions of the disk, abd also define how many zeros to write.

If you want to zerofill a specific partition, consider using the appropriate block device instead.

But, purely as an example... let's say you wanted to fill the 1st 4mb of a disk with zeros...

dd if=/dev/zero of=/dev/sda bs=1m count=4

bs= defines the 'block size', and is measured in mebibyte/kibibyte/gibibyte. Otherwise, its a size in bytes.

count= defines how many blocks to write.

In the example above, 4 1-mebibyte blocks.

Now, assume you wanted to write 4mb of zeros immediately after the first gibibyte of the disk:

dd if=/dev/zero of=/dev/sda bs=1m count=4 seek=1024

Be mindful that disk structures are not 0 bytes in size.

If you want to blank a single partition, it's better to use the partition's block device instead of the raw disk.

Say for instance, you want to blank partition 3 on /dev/sda

dd if=/dev/zero of=/dev/sda3 bs=4k status=progress

Be mindful that dd does not have guardrails.

TRIPLE CHECK your of= declaration.

DD is complcated and I will make a mistake. It needs a thorough reading as it is powerful.

Tried Victoria and it was enough to avoid nuking my whole PC.

Thanks for the inputs!!

Great!

Now that that is done and time is no longer of the essence, I would also like to chime in and recommend mastering dd - it is a very versatile and powerful tool.

st31276a wrote on 2025-03-08, 07:48:

Great!

Now that that is done and time is no longer of the essence, I would also like to chime in and recommend mastering dd - it is a very versatile and powerful tool.

I need to learn how HDD/SDD work, like LBA and how to calculate sizes.
Geometries and more stuff I had no clue about.

As long as you know what you are doing it allows to do a lot.

Since it's a 6TB, is it an HDD rather than SSD? If so, and you didn't delete the files yet you might be able to use the information in this post. It mentioned shred which overwrites a files multiple times with random data, or the wipe tool.

https://askubuntu.com/questions/57572/how-to- … n-secure-manner

This depends on the file system you're using as well. ZFS will write any changes to free sectors as it's a copy on write filesystem. Others do journaling, which can which is a similar thing and you need to wipe the full partition.

A better method is using full disk encryption. No key? Can't get at the data.

Is not deleting old date/files, and rewriting new data/files sufficient? What does it matter if it's zero or other values? If your drive is defragmented, and you delete a file,any file saved should load to the same location, no? If this isn't the case, these computer are hazards tomour health.

Perhaps you should have a separate small SSD to which this sensitive data is written.

SScorpio wrote on 2025-03-08, 13:43:

Since it's a 6TB, is it an HDD rather than SSD? If so, and you didn't delete the files yet you might be able to use the informat […]
Show full quote

Since it's a 6TB, is it an HDD rather than SSD? If so, and you didn't delete the files yet you might be able to use the information in this post. It mentioned shred which overwrites a files multiple times with random data, or the wipe tool.

https://askubuntu.com/questions/57572/how-to- … n-secure-manner

This depends on the file system you're using as well. ZFS will write any changes to free sectors as it's a copy on write filesystem. Others do journaling, which can which is a similar thing and you need to wipe the full partition.

A better method is using full disk encryption. No key? Can't get at the data.

yes, it is a HDD. A pretty heavy brick too... 😀 Let that fall on your foot! 🤣

Dude, I really need to learn stuff.
You are mentioning things I'm unfamiliar with (i.e. no clue).

I just copied a few .raw files of my walks in the woods to test the write speed of the disk. Like 300GB at best.
Absolutely no sensitive data. Then I noticed that the disk was made in 2020 and checked for warranty and found it was part of a bigger system (prolly sold in some machine set and then resold because of no use or was bought in bulk with replacements- my guess). Assistance said if the company/seller closed I'd be out of warranty. I'm gonna spend a few euros more and buy new "new" not NOS.

Nexxen wrote on 2025-03-08, 14:10:

yes, it is a HDD. A pretty heavy brick too... :) Let that fall on your foot! LOL […]
Show full quote

yes, it is a HDD. A pretty heavy brick too... 😀 Let that fall on your foot! 🤣

Dude, I really need to learn stuff.
You are mentioning things I'm unfamiliar with (i.e. no clue).

I just copied a few .raw files of my walks in the woods to test the write speed of the disk. Like 300GB at best.
Absolutely no sensitive data. Then I noticed that the disk was made in 2020 and checked for warranty and found it was part of a bigger system (prolly sold in some machine set and then resold because of no use or was bought in bulk with replacements- my guess). Assistance said if the company/seller closed I'd be out of warranty. I'm gonna spend a few euros more and buy new "new" not NOS.

Many modern filesystems have some type of journal support. This allows you to have power to the drive go out while it's making writes, but not corrupt a file that was being overwritten as the write never finished so it reverts back to the original copy of the file. This means you could have copies of a file all over a drive. So if you are worried, just use full drive encryption. No data can be pulled from the drive without the key. It would be losing access to the computer and a person trying to recover files from the running machine. If a drive was just pulled from the system, the data isn't readable anywhere else.

SSDs are harder too deal with. The controller prevents direct access. But most of a secure erase command. Just issue that and if the drive has power, it will securely erase itself, even if not being used by an OS. It just needs power for the controller to do its thing.

SScorpio wrote on 2025-03-08, 17:02:

Nexxen wrote on 2025-03-08, 14:10:

yes, it is a HDD. A pretty heavy brick too... :) Let that fall on your foot! LOL […]
Show full quote

yes, it is a HDD. A pretty heavy brick too... 😀 Let that fall on your foot! 🤣

Dude, I really need to learn stuff.
You are mentioning things I'm unfamiliar with (i.e. no clue).

I just copied a few .raw files of my walks in the woods to test the write speed of the disk. Like 300GB at best.
Absolutely no sensitive data. Then I noticed that the disk was made in 2020 and checked for warranty and found it was part of a bigger system (prolly sold in some machine set and then resold because of no use or was bought in bulk with replacements- my guess). Assistance said if the company/seller closed I'd be out of warranty. I'm gonna spend a few euros more and buy new "new" not NOS.

Many modern filesystems have some type of journal support. This allows you to have power to the drive go out while it's making writes, but not corrupt a file that was being overwritten as the write never finished so it reverts back to the original copy of the file. This means you could have copies of a file all over a drive. So if you are worried, just use full drive encryption. No data can be pulled from the drive without the key. It would be losing access to the computer and a person trying to recover files from the running machine. If a drive was just pulled from the system, the data isn't readable anywhere else.

SSDs are harder too deal with. The controller prevents direct access. But most of a secure erase command. Just issue that and if the drive has power, it will securely erase itself, even if not being used by an OS. It just needs power for the controller to do its thing.

I definitely have to watch some YT video about it.
This is interesting.
wow, one question opened a world

smartmontools package for linux has smartctl, which you can use to initiate secure-erase.

However, making then formatting a blank partition, issuing TRIM, then zero-filling would cause an SSD to overwrite the previously trimmed cells.

It might be faster than secure-erase.

wierd_w wrote on 2025-03-10, 17:12:

smartmontools package for linux has smartctl, which you can use to initiate secure-erase.

However, making then formatting a blank partition, issuing TRIM, then zero-filling would cause an SSD to overwrite the previously trimmed cells.

It might be faster than secure-erase.

Thanks.
I've been looking for something explaining how HDD work, from mechanical to LBA... tracks and sectors, but didn't really find anything complete.
Do you perhaps have a suggestion where to look, some book... anything?

I've watched some interesting videos by Adrian Black on floppy disks (and how to calibrate floppy drives etc).
I'm not an expert on anything but I've come to the time where I must level up on a few basic things.

Encryption hasn't been on my to learn list but time has come to give a spin at that too (yes, most IT guys here are gonna laugh).

wierd_w - Yes - ATA secure erase is also an option, however it is a command that the device must explicitly support. They tend to do that for the last two decades or so, however.

Nexxen - I do not know of a specific authoritative source on this, I picked up what I know by reading the manual pages of tools like smartctl and hdparm and doing stuff with block devices. I will just write a couple of introductory sentences about some interesting stuff about hard drives in general I can think about at the moment.

A hard disk is basically a long string of blocks (LBAs) that are numbered 0 to n-1. They typically were 512 bytes up until the "Advanced Format" disks came along around when 2TB was popular, with 4096 bytes sectors. The larger sectors are great for using more robust forward error correction codes when writing to the media, so that manufacturers can of course skimp and run tighter margins on signal integrity. The larger physical sectors are typically still presented as a string of 512 byte LBAs, where 8 logical sectors sit inside one physical sector. Therefore it is important to align partitions / file systems so that file system sectors align with the underlying physical sectors for performance reasons - otherwise one sector write becomes two read-modify-writes.

After that, SMR hard disks rolled around that pretend to be working like flash, since they have a TRIM command. They write their data tracks slightly overlapping in order to get higher track density. Data can only be written sequentially in this style, random writes would muck up the tracks that are stacked like ploughed furrows. It has a small section with normal randomly writable tracks where writes get cached. An advanced controller then maps LBAs to physical locations, whether in a SMR block or in the CMR cache. The controller goes when there is no disk activity and reads SMR blocks that have writes destined, reads the writes from the cache and rewrites the SMR blocks in sequential fashion, the only way they can be written. These SMR blocks are typically 32MB-256MB in size. The controller keeps track of which blocks contain what, and can take TRIM hints to discard completely unused blocks instead of re-writing them unnecessarily. SMR hard disks perform bad under heavy random write loads (or badly overall, depending whom you ask) and are best avoided.

Using the smartctl tool to query hard drives yields very interesting information. If you do that a couple of times on a couple of disks and chase every rabbit you see down its hole, you will not only have been busy for a while, but hopefully also had a good time 😀

I remember running a quick performance benchmark on a brand new SMR drive.
Epic throughput.
.. because the drive knew there wasn't any data allocated to the LBAs being queried, so it responded to almost the entire benchmark without reading anything from the platters.
SMR drives seem to act like SSDs, with a layer of indirection between the LBA and the physical storage. So if the LBA has never been used, they have no data to respond with but an automatic '0'.

Now I'm at the opposite end of the experience. That drive is a dog. But SMR is okay if it's just for semi-permanent storage that won't be rewritten often, and you don't need it to be fast.

shamino wrote on 2025-03-11, 23:49:

But SMR is okay if it's just for semi-permanent storage that won't be rewritten often, and you don't need it to be fast.

Exactly!

SMR as the only drive sucks.
The way to go is: SSD for the system and working files + SMR for terabytes of rarely used stuff.