Difference between revisions of "Talk:Securely wipe disk"

From ArchWiki
Jump to: navigation, search
(Logical emulation of block size: new section)
(on the bashing of /dev/urandom: move it to Talk:random)
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Average block size==
+
== Block size ==
 +
=== Average block size ===
 
Based on my intuition I agree with [[User:Nonix|Nonix]]'s statement in the Accuracy template, which is located at the top of the [[Securely_wipe_disk#Overwrite_the_disk|Overwrite the disk]] section. A common block size of 4096 bytes is equivalent to 4KB. ~ [[User:Filam|Filam]] ([[User talk:Filam|talk]]) 03:29, 21 September 2012 (UTC)
 
Based on my intuition I agree with [[User:Nonix|Nonix]]'s statement in the Accuracy template, which is located at the top of the [[Securely_wipe_disk#Overwrite_the_disk|Overwrite the disk]] section. A common block size of 4096 bytes is equivalent to 4KB. ~ [[User:Filam|Filam]] ([[User talk:Filam|talk]]) 03:29, 21 September 2012 (UTC)
  
 
:Just fixed it!
 
:Just fixed it!
:(For the record only: The article suggested using blocksizes of 4MB!)
+
:(For the record only: The article suggested using blocksizes of 4MB!) --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 10:55, 21 September 2012 (UTC)
:I was unsure about the capabilities of dumpe2fs, so i wrote a new accuracy-TP. It works on Filesystem-layer so i think it's not suitable for 512e. Besides it assumes a working filesystem directly written on the device. Feel free to remove the Template if you know better. :) --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 10:55, 21 September 2012 (UTC)
+
  
== Logical emulation of block size ==
+
::Badblocks per default does test 64 KB in 1 KB blocks at a time. [[Securely_wipe_disk#Badblocks|Here]] it's suggested up to now to test 10 MB in 1 KB blocks. ({{ic|-c 10240}})
 +
::Is something wrong with the general aim of the [[Securely_wipe_disk#Block_size|#Block size]] section to align block size to physical geometry and write it block by block? Or is this aimed at no-HDD Storage?
 +
::Note what [[Wikipedia:Badblocks#badblocks.27s_.22-c.22_option|Wikipedia has to say in the matter]]. On the other hand they say only "scan"-speed, not writing speed. Review is needed here. --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 00:06, 27 September 2012 (UTC)
  
I removed [https://wiki.archlinux.org/index.php?title=Securely_wipe_disk&diff=224314&oldid=224225 Nonix's Accuracy template] regarding logical emulation of block size since the article does not reference it. Therefore the accuracy of the article is not in question. However, it is a fair point of discussion. Nonix wrote:
+
=== Logical emulation of block size ===
:Does dumpe2fs recognize 512e-discs? (4K physical sectors on the drive media with 512 byte logical emulation)
+
I was unsure about the capabilities of dumpe2fs, so i wrote a new accuracy-TP. It works on Filesystem-layer so i think it's not suitable for 512e. Besides it assumes a working filesystem directly written on the device. Feel free to remove the Template if you know better. :) --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 10:55, 21 September 2012 (UTC)
~ [[User:Filam|Filam]] ([[User talk:Filam|talk]]) 14:17, 21 September 2012 (UTC)
+
 
 +
:I removed [https://wiki.archlinux.org/index.php?title=Securely_wipe_disk&diff=224314&oldid=224225 Nonix's Accuracy template] regarding logical emulation of block size since the article does not reference it. Therefore the accuracy of the article is not in question. However, it is a fair point of discussion. Nonix wrote:
 +
::Does dumpe2fs recognize 512e-discs? (4K physical sectors on the drive media with 512 byte logical emulation)
 +
:~ [[User:Filam|Filam]] ([[User talk:Filam|talk]]) 14:17, 21 September 2012 (UTC)
 +
 
 +
::I updated the [[Securely_wipe_disk#Select_a_target|Section on fdisk]]. Fdisk should be the standard tool for the logical and physical Sector size printing-job. It can detect 512e as I read in a magazine tough I don't know if it always does. Any objections? --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 11:01, 27 September 2012 (UTC)
 +
 
 +
== How about including shred instead of or along with badblocks ==
 +
I just used it recently and it worked great.
 +
 
 +
  # shred -v -n 1 /dev/sdb
 +
  ...
 +
  shred: /dev/sdb: pass 1/1 (random)...572GiB/932GiB 61%
 +
  shred: /dev/sdb: pass 1/1 (random)...573GiB/932GiB 61%
 +
  shred: /dev/sdb: pass 1/1 (random)...574GiB/932GiB 62%
 +
  shred: /dev/sdb: pass 1/1 (random)...575GiB/932GiB 62%
 +
  shred: /dev/sdb: pass 1/1 (random)...576GiB/932GiB 63%
 +
 
 +
Are there any objections or complaints about this tool? My experience was that it was A LOT faster then using /dev/random as well, and it provides display to the user of the progress. Id say it should be the first recommended option.
 +
[[User:MrSk1yj8|MrSk1yj8]] ([[User talk:MrSk1yj8|talk]]) 29 July 2012
 +
 
 +
:I agree and took the freedom to add shred. However, the random source is an intrinsic to dm-crypt. A great feature of shred is that you can choose to use a random source other than the default (see wiki example). So you can actually use /dev/urandom or whatever you prefer. That (together with -v progress view) makes it a great replacement to dd in my view. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:23, 17 September 2012 (UTC)

Revision as of 13:01, 1 October 2012

Block size

Average block size

Based on my intuition I agree with Nonix's statement in the Accuracy template, which is located at the top of the Overwrite the disk section. A common block size of 4096 bytes is equivalent to 4KB. ~ Filam (talk) 03:29, 21 September 2012 (UTC)

Just fixed it!
(For the record only: The article suggested using blocksizes of 4MB!) --Nonix (talk) 10:55, 21 September 2012 (UTC)
Badblocks per default does test 64 KB in 1 KB blocks at a time. Here it's suggested up to now to test 10 MB in 1 KB blocks. (-c 10240)
Is something wrong with the general aim of the #Block size section to align block size to physical geometry and write it block by block? Or is this aimed at no-HDD Storage?
Note what Wikipedia has to say in the matter. On the other hand they say only "scan"-speed, not writing speed. Review is needed here. --Nonix (talk) 00:06, 27 September 2012 (UTC)

Logical emulation of block size

I was unsure about the capabilities of dumpe2fs, so i wrote a new accuracy-TP. It works on Filesystem-layer so i think it's not suitable for 512e. Besides it assumes a working filesystem directly written on the device. Feel free to remove the Template if you know better. :) --Nonix (talk) 10:55, 21 September 2012 (UTC)

I removed Nonix's Accuracy template regarding logical emulation of block size since the article does not reference it. Therefore the accuracy of the article is not in question. However, it is a fair point of discussion. Nonix wrote:
Does dumpe2fs recognize 512e-discs? (4K physical sectors on the drive media with 512 byte logical emulation)
~ Filam (talk) 14:17, 21 September 2012 (UTC)
I updated the Section on fdisk. Fdisk should be the standard tool for the logical and physical Sector size printing-job. It can detect 512e as I read in a magazine tough I don't know if it always does. Any objections? --Nonix (talk) 11:01, 27 September 2012 (UTC)

How about including shred instead of or along with badblocks

I just used it recently and it worked great.

 # shred -v -n 1 /dev/sdb
 ...
 shred: /dev/sdb: pass 1/1 (random)...572GiB/932GiB 61%
 shred: /dev/sdb: pass 1/1 (random)...573GiB/932GiB 61%
 shred: /dev/sdb: pass 1/1 (random)...574GiB/932GiB 62%
 shred: /dev/sdb: pass 1/1 (random)...575GiB/932GiB 62%
 shred: /dev/sdb: pass 1/1 (random)...576GiB/932GiB 63%

Are there any objections or complaints about this tool? My experience was that it was A LOT faster then using /dev/random as well, and it provides display to the user of the progress. Id say it should be the first recommended option. MrSk1yj8 (talk) 29 July 2012

I agree and took the freedom to add shred. However, the random source is an intrinsic to dm-crypt. A great feature of shred is that you can choose to use a random source other than the default (see wiki example). So you can actually use /dev/urandom or whatever you prefer. That (together with -v progress view) makes it a great replacement to dd in my view. --Indigo (talk) 20:23, 17 September 2012 (UTC)