You are not logged in.
I recently got a 10TB external HDD and began the process of encrypting it with dm-crypt. Following the steps in this guide, I started the process to wipe the drive with random data with this method. The wipe process ran smoothly for a few days until I needed to reboot the computer for something and completely forgot that the drive was not finished writing. Now when I repeat the steps and attempt to rerun the
dd if=/dev/zero of=/dev/mapper/to_be_wiped status=progress bs=1Mcommand, I get the error
dd: error writing 'dev/mapper/to_be_wiped': No space left on deviceI'm fairly sure the drive had not completely written the rest of the drive so I'm checking in here to ask if there's any damage done to the drive or additional steps I should take before creating an encrypted partition? This was a brand new drive so I did not lose any data but I want to ensure it will be fully functional. Thanks!
Last edited by babel_f1sh (2024-12-09 17:55:42)
Offline
I assume, that you’re receiving this message instantly after invoking `dd`. If not, please post the entire output.
What is “/dev/mapper/to_be_wiped” exactly in your case? How do you make this entry to appear? Sounds a bit like a wrong thing is being placed there.
The guide calls for filling the unlocked encrypted container with zeros. If you did that, then whatever happened during rebooting and whatever got broken is only the container itself or inside the container. So no worries here about anything getting damaged.
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
how is that drive connected as 10tb should not take "a few days"
my external drive uses usb 3.0 5gbit/s and is 2tb in size - when I take it to a friend to share data he can fill it in not that much of time
Offline
how is that drive connected as 10tb should not take "a few days"
my external drive uses usb 3.0 5gbit/s and is 2tb in size - when I take it to a friend to share data he can fill it in not that much of time
I've read that wiping a drive with random bytes as I did can take quite some time so it didn't really surprise me. The write speed for this process was ~40.5 mb/s
Edit: the guide says it's wiping with zeros which is supposed to be faster than random bytes but it's still a large drive so I'm not concerned about the speed.
Last edited by babel_f1sh (2024-12-09 09:03:50)
Offline
I assume, that you’re receiving this message instantly after invoking `dd`. If not, please post the entire output.
What is “/dev/mapper/to_be_wiped” exactly in your case? How do you make this entry to appear? Sounds a bit like a wrong thing is being placed there.
The guide calls for filling the unlocked encrypted container with zeros. If you did that, then whatever happened during rebooting and whatever got broken is only the container itself or inside the container. So no worries here about anything getting damaged.
I was following these steps. I think the to_be_wiped is the label for the temporary encrypted partition. I was going to post the full output in this reply that basically said a few gigabytes were written and then output the error message but I disconnected the drive and ran the above steps again and now it seems to have started the writing process over and is running smoothly. I guess I was a bit hasty to post but I'll update if any other errors arise. Thanks for the reassurance about damage!
Offline
~40.5 mb/s
wow - that's a slow ass drive for a new 10tb one - or it's how the drive is connected
even SMR drives should be 3-digit for sequential bulk writes - somewhere north of 150-200mb/s (for sequential)
if possible I would get it out the obvious very limiting enclosure and hook it up internal - at least for the initial wipe
for the long run maybe consider a new external enclosure which doesn't tank as hard
if tge drive is still that slow even when hooked up internal I would refund it as not up to spec - which is likely marketed with something faster than what you get
or the system the drive is connected to is the bottleneck like a 15 year old intel celeron or atom or an amd phenom ...
Offline
babel_f1sh wrote:~40.5 mb/s
wow - that's a slow ass drive for a new 10tb one - or it's how the drive is connected
even SMR drives should be 3-digit for sequential bulk writes - somewhere north of 150-200mb/s (for sequential)
if possible I would get it out the obvious very limiting enclosure and hook it up internal - at least for the initial wipe
for the long run maybe consider a new external enclosure which doesn't tank as hard
if tge drive is still that slow even when hooked up internal I would refund it as not up to spec - which is likely marketed with something faster than what you getor the system the drive is connected to is the bottleneck like a 15 year old intel celeron or atom or an amd phenom ...
Thanks for encouraging me to check this! I think the issue was that I unknowingly hooked it up to a USB 2.0 port so it was running much slower than it needed to be. It's plugged into a USB 3.0 port now and writing at about 200mb/s so the process should go a bit faster this time around.
Offline
It's plugged into a USB 3.0 port now and writing at about 200mb/s
that's in the realm of what to be expected
I think the issue was that I unknowingly hooked it up to a USB 2.0 port
actually I'm not sure about common desktop environments for linux - but credit where credit is due: windows yells at you about that with some message like "this device can perform better when connected to a different port" - and even in dmesg that's just an info instead of something more serious like a warn or such (yes, it's technical not a warn as it does work anyway - but a normal info often just isn't logged unless verbose logging is enabled)
Offline