| View previous topic :: View next topic |
| Author |
Message |
etnull
Tux's lil' helper
Joined: 26 Mar 2019
Posts: 143
|
 Posted: Thu Apr 25, 2019 6:19 pm Post subject: [SOLVED] blkid shows pttype="atari" |
 |
|
I wiped my hdd with urandom, like so
| Code: | | dd if=/dev/urandom of=/dev/sdX bs=512 seek=0 status=progress |
then I partitioned it with
| Code: | parted -a optimal /dev/sdX
unit mib
mklabel gpt
mkpart primary 0% 100%
quit |
then I encrypted it with cryptsetup using detached LUKS header,
and finally I formatted the mounted crypt volume with ext4
Now blkid shows me some weird atari PTTYPE:
| Quote: | | /dev/sdX1: PTTYPE="atari" PARTUUID="2c66334e-5228-41e0-b887-22bd258e47d8" |
I did the exact same manipulations, with the exception of additional round of zeros on top of the crypt volume of another SSD drive, and It don't have anything of this sort.
Can blkid see something in random data? How so if it was formatted with ext4 anyway?
What is atari partition type and should I be worry about it? My HDD is 2TB.
Can I wipe PTTYPE without reformatting the drive? Thanks.
Last edited by etnull on Thu Apr 25, 2019 11:53 pm; edited 1 time in total |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 5761
|
| Posted: Thu Apr 25, 2019 7:05 pm Post subject: |
|
|
| Garbage in, garbage out. How do you expect blkid to know that some bytes are random noise and not a filesystem header? |
|
| Back to top |
|
|
etnull
Tux's lil' helper
Joined: 26 Mar 2019
Posts: 143
|
| Posted: Thu Apr 25, 2019 7:36 pm Post subject: |
|
|
| Ant P. wrote: | | Garbage in, garbage out. How do you expect blkid to know that some bytes are random noise and not a filesystem header? |
well gpt and ext4 was put after the /dev/urandom. shouldn't it provide all information needed? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 43197
Location: 56N 3W
|
| Posted: Thu Apr 25, 2019 8:11 pm Post subject: |
|
|
etnull,
| Code: | | mkpart primary 0% 100% |
You didn't set a fs-type and parted left whatever was there unchanged.
| man parted: | mkpart part-type [fs-type] start end
Make a part-type partition for filesystem fs-type (if specified), beginning at start
and ending at end (by default in megabytes). part-type should be one of "primary",
"logical", or "extended". |
What is set there is not related in any way to what is actually on the partition.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 13845
|
| Posted: Fri Apr 26, 2019 1:25 am Post subject: Re: [SOLVED] blkid shows pttype="atari" |
|
|
| etnull wrote: | | I did the exact same manipulations, with the exception of additional round of zeros on top of the crypt volume of another SSD drive, and It don't have anything of this sort. |
Why did you do this? If you use trim afterward, you will have wasted the effort. If you don't use trim, you will have the entire drive marked as busy, so every write requires an erase cycle. Modern SSDs are better about this than some of the early models, but it's still not free. Does your threat model require paying this cost? |
|
| Back to top |
|
|
etnull
Tux's lil' helper
Joined: 26 Mar 2019
Posts: 143
|
| Posted: Fri Apr 26, 2019 11:17 am Post subject: Re: [SOLVED] blkid shows pttype="atari" |
|
|
| Hu wrote: | | etnull wrote: | | I did the exact same manipulations, with the exception of additional round of zeros on top of the crypt volume of another SSD drive, and It don't have anything of this sort. |
Why did you do this? If you use trim afterward, you will have wasted the effort. If you don't use trim, you will have the entire drive marked as busy, so every write requires an erase cycle. Modern SSDs are better about this than some of the early models, but it's still not free. Does your threat model require paying this cost? |
I do random fill to "level the playing field" and make it a one chunk of mess. Then I do round of zeros on top of the encrypted luks volume for my ssd, exactly for that, to not confuse the controller and trim. I do trim weekly via cron. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 43197
Location: 56N 3W
|
| Posted: Fri Apr 26, 2019 5:55 pm Post subject: |
|
|
etnull,
Writing zeros is still writing. The space is marked as in use. Its not the same to the drive as trimmed space, which is tagged as erased and ready for a write.
Also writing zeros to the encrypted layer will not write zeros to the SSD.
Trim, if it works, will result in lots of erased space on the SSD, which is what filling it with random bytes is designed to avoid.
If your threat model requires that an attacker cannot locate the in use data areas of your drive, think twice about using an SSD because the write performance will be terrible.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
etnull
Tux's lil' helper
Joined: 26 Mar 2019
Posts: 143
|
| Posted: Sat Apr 27, 2019 12:33 pm Post subject: |
|
|
| NeddySeagoon wrote: | | Writing zeros is still writing. The space is marked as in use. |
Ok then, how do I restore my SSD performance after random fill? If I run TRIM will it mark all zeros as a free space or something?
Also I would still like to do that (random fill) for HDD, but without getting this atari thing, if I dd with zeros first couple of megabytes will it be enough? is dd writes from beginning of the platter? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 43197
Location: 56N 3W
|
| Posted: Sat Apr 27, 2019 1:48 pm Post subject: |
|
|
etnull,
A random fill and SSD performance are mutually exclusive.
Trim tells the the SSD that whenever its convenient, it can erase the space that's been trimmed.
Its not a command to the drive to do it now, when it happens depends on the pressure on free space, among other things.
SSDs have different size erase blocks and write blocks. This means that the SSD cannot trim (erase) a single write block.
For a worked example, lets say an erase block is 64 write blocks.
If all 64 write blocks in the erase block are to be trimmed, its easy, erase the whole thing.
It gets more complex when write blocks need to be moved. It also consumes some of the drives write life.
Suppose one write block needs to be preserved. The drive copies that block to a different erase block, incurring a write, does some house keeping, so the operating system doesn't notice.
then erases the now empty erase block. The process is the same however many write blocks need to be preserved.
These extra writes, required to empty an entire erase block, are a bad thing. Its a feature of all SSDs called 'write amplification'.
Now lets extend this to an entire SSD with lots of part trimmed (used but containing discarded write blocks) erase blocks. The firmware tries to minimise write amplification, so it puts off moving write blocks around as much as it can. After all, more space may be trimmed before it needs to do anything, which could result in free erase blocks which can be erased without any write amplification.
An erase cycle is not the same as writing zeros. Writing zeros does not change the data in an erased area but the drive doesn't know that. Its now used.
Its gets more complex still when you add in wear levelling but I'll stop there.
-- edit --
If you don't want a random filesystem type, use gparted to set the filesystem type on the partition.
It has no effect on the content of the partition.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
etnull
Tux's lil' helper
Joined: 26 Mar 2019
Posts: 143
|
| Posted: Sat Apr 27, 2019 1:54 pm Post subject: |
|
|
NeddySeagoon
What I meant is that after I did a random fill, how do I restore it to the original state, so that the controller and TRIM know that all space is free and no double write is needed? If writing zeros won't help? |
|
| Back to top |
|
|
mike155
Veteran
Joined: 17 Sep 2010
Posts: 1294
Location: Frankfurt, Germany
|
| Posted: Sat Apr 27, 2019 2:00 pm Post subject: |
|
|
| Quote: | | What I meant is that after I did a random fill, how do I restore it to the original state, so that the controller and TRIM know that all space is free and no double write is needed? |
You could either use blkdiscard (part of the util-linux package) or you could use the drive's security erase feature.
See: https://askubuntu.com/questions/42266/what-is-the-recommended-way-to-empty-a-ssd
Last edited by mike155 on Sat Apr 27, 2019 2:03 pm; edited 1 time in total |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 43197
Location: 56N 3W
|
| Posted: Sat Apr 27, 2019 2:01 pm Post subject: |
|
|
etnull,
You can only force it to happen with a security erase command. That erases the entire SSD.
Take great care with that as most HDD support the security erase command too.
It cannot be stopped.
If you use fstrim on the filesystems on the SSD, that will tell the drive that the free space can be be erased. However, when it happens is up to the firmware.
The firmware will try to keep ahead of any writes, so you don't have to wait for erase cycles.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
Installing Gentoo
