USB 드라이브를 포맷하고 모두 0으로 채워졌는지 확인하고 싶습니다. 포맷을 위해 이것은 내가 사용하는 명령입니다:
sudo mkfs.vfat -I /dev/sdb
명령줄을 통해 장치가 모두 0으로 채워졌는지 어떻게 확인합니까?
답변1
나도 여기 링에 모자를 던질 것이다. 제가 즐겨 사용하는 대안 중 하나는 입니다 scrub. 저장소에 있으므로 터미널 창에서 설치하려면 다음을 입력하십시오.
sudo apt-get install scrub
scrub다양한 유형의 스크러빙 패턴 지원
Available patterns are:
nnsa 3-pass NNSA NAP-14.1-C
dod 3-pass DoD 5220.22-M
bsi 9-pass BSI
usarmy 3-pass US Army AR380-19
random 1-pass One Random Pass
random2 2-pass Two Random Passes
schneier 7-pass Bruce Schneier Algorithm
pfitzner7 7-pass Roy Pfitzner 7-random-pass method
pfitzner33 33-pass Roy Pfitzner 33-random-pass method
gutmann 35-pass Gutmann
fastold 4-pass pre v1.7 scrub (skip random)
old 5-pass pre v1.7 scrub
dirent 6-pass dirent
fillzero 1-pass Quick Fill with 0x00
fillff 1-pass Quick Fill with 0xff
custom 1-pass custom="string" 16b max, use escapes \xnn, \nnn, \\
scrub드라이브를 모두 채우려면 먼저 zeros드라이브가 마운트되어 있지 않은지 확인하십시오. 그런 다음 다음 줄을 실행합니다( -p사용할 패턴을 의미).
sudo scrub -p fillzero /dev/sdX
그러면 다음과 같은 내용이 표시됩니다.
scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00 |..... |
스크러빙에 사용되는 일부 패턴에는 verify스크러빙이 통과되었는지 확인하기 위한 패스가 있어야 합니다.
원하는 경우 hexdump(Byte Commander의 답변에서와 같이) 확인을 위해 끝에 다른 답변을 추가할 수 있습니다.
도움이 되었기를 바랍니다!
답변2
신청하고 dd, tr가상검사를 하려면:
dd if=/dev/sdb | tr '\0' 0
신청 dd및 grep자동 확인:
dd if=/dev/sdb | grep -zq . && echo non zero
위의 명령은 아래의 최적화된 명령보다 훨씬 느립니다.
grep -zq . /dev/sdb && echo non zero
grep -znull로 구분된 줄을 읽습니다. 모든 바이트가 null이면 각 줄은 비어 있으므로 .일치해서는 안 됩니다.
물론 포맷된 파티션에서는 그렇지 않습니다. 포맷 시스템은 일부 바이트를 사용하며 null이 아닙니다.
답변3
내 제안은 입니다 hexdump. 16진수 형식의 모든 파일이나 장치의 내용을 16바이트 행으로 표시하지만 후속 두 줄이 동일하면 생략합니다.
virtualdevice다음은 내 HDD의 현재 디렉터리에만 0으로 채워지는 512MB 파일의 출력 예입니다 . 가장 왼쪽 열은 16진수 표기법으로 된 행의 오프셋이고, 다음 8개 열은 2바이트(4개의 16진수 문자)로 그룹화된 실제 데이터입니다.
$ hexdump ./virtualdevice
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000
성능:
나는 노력을 기울였고 설명된 예제 파일(512MB, 이진 0만 포함하고 HDD에 있음)에 대한 실제 런타임 및 CPU 시간을 기준으로 내 솔루션을 다른 솔루션과 비교했습니다.
time새로 지워진 디스크 캐시를 사용하여 두 번, 이미 캐시된 파일을 사용하여 두 번 명령을 사용하여 모든 솔루션을 측정했습니다 . 시간 이름은 time명령의 이름과 동일하며 추가 행 은 + 시간 CPU의 합계입니다 . 듀얼 코어 머신을 실행하고 있기 때문에 시간이 초과될 수 있습니다 .USERSYSREAL
대부분의 사람들에게 흥미로운 수치는 REAL(초시계로 측정한 것처럼 처음부터 끝까지의 시간입니다. 여기에는 다른 프로세스의 IO 대기 및 CPU 시간도 포함됩니다) 및 CPU(명령이 실제로 차지하는 CPU 시간)이 있습니다.
요약:
최고의 성능은무루grep -zq . DEVICE엄청나게 적은 CPU 처리 시간을 사용하는 의 최적화된 두 번째 버전( )입니다 .
2위 점유율 cmp /dev/zero DEVICE(코스'최적화된 솔루션)과 나만의 솔루션 hexdump DEVICE. 그들 사이에는 거의 차이가 없습니다.
데이터 를 dd( cmp-dd if=/dev/zero | cmp - DEVICE코스'최적화되지 않은 솔루션)은 매우 비효율적이며 배관에 많은 처리 시간이 소요되는 것 같습니다. 테스트된 명령 중 최악의 성능을
사용하여 dd보여 줍니다.grep
결론:
이와 같은 작업에서 가장 중요한 부분은 IO 액세스 시간이지만 테스트된 접근 방식의 처리 속도와 효율성에는 상당한 차이가 있습니다.
참을성이 없으면 두 번째 버전을 사용하십시오.무루님의 답변 ( grep -zq . DEVICE)!
하지만 두 번째 버전 중 하나를 사용할 수도 있습니다.코스' 답변 ( cmp /dev/zero DEVICE) 또는 내 답변 ( hexdump device)이 거의 성능이 좋기 때문입니다.
그러나 내 접근 방식에는 파일 내용을 즉시 확인하고 0과 다른 바이트 수와 위치를 대략적으로 알 수 있다는 장점이 있습니다. 그러나 교번 데이터가 많으면 출력이 커지고 속도가 느려질 수 있습니다.
어떤 경우에도 피해야 할 것은 dd파이프를 사용하는 것입니다. 적절한 버퍼 크기를 설정하면 성능이 dd향상될 수 있지만 왜 그렇게 복잡한 방식으로 수행합니까?
테스트는 실제 장치가 아닌 내 디스크에 있는 파일을 대상으로 수행되었음을 다시 한 번 참고하시기 바랍니다. 또한 파일에는 0만 포함되어 있습니다. 둘 다 성능에 영향을 미칩니다.
자세한 결과는 다음과 같습니다.
hexdump ./virtualdevice(내 자신의 솔루션):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.689s 8.668s | 1.868s 1.930s USER | 1.816s 1.720s | 1.572s 1.696s SYS | 0.408s 0.504s | 0.276s 0.220s CPU | 2.224s 2.224s | 1.848s 1.916sdd if=./virtualdevice | grep -zq . && echo non zero(무루님의 최적화되지 않은 솔루션):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 9.434s 11.004s | 8.802s 9.266s USER | 2.264s 2.364s | 2.480s 2.528s SYS | 12.876s 12.972s | 12.676s 13.300s CPU | 15.140s 15.336s | 15.156s 15.828sgrep -zq . ./virtualdevice && echo non zero(무루의 최적화된 솔루션):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 8.763s 6.485s | 0.770s 0.833s USER | 0.644s 0.612s | 0.528s 0.544s SYS | 0.440s 0.476s | 0.236s 0.264s CPU | 1.084s 1.088s | 0.764s 0.808sdd if=/dev/zero | cmp - ./virtualdevice(코스' 솔루션이 최적화되지 않음):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.678s 6.539s | 3.151s 3.147s USER | 2.348s 2.228s | 2.164s 2.324s SYS | 3.672s 3.852s | 3.792s 3.516s CPU | 6.020s 6.080s | 5.956s 5.840scmp /dev/zero ./virtualdevice(코스' 솔루션 최적화):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 6.340s 9.183s | 1.660s 1.660s USER | 1.356s 1.384s | 1.216s 1.288s SYS | 0.640s 0.596s | 0.428s 0.360s CPU | 1.996s 1.980s | 1.644s 1.648s
사용된 명령:
네 가지 테스트 모두에 대해 다음 절차를 실행했습니다.두 배부정확성을 줄이기 위해 <COMMAND>각 테이블의 헤드라인에 있는 정확한 명령으로 대체합니다.
커널이 모든 디스크 캐시를 삭제하도록 합니다.
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches최초 실행(캐시되지 않음), 다음 과정에서 파일이 캐시에 로드됩니다.
time <COMMAND>두 번째 시간 초과 실행(캐시됨) 이번에는 대부분의 데이터를 RAM의 디스크 캐시에서 가져오므로 디스크에 직접 액세스할 때보다 훨씬 빠릅니다.
time <COMMAND>
답변4
사용 cmp(파이프 사용의 어리석음을 지적한 muru에게 감사드립니다):
sudo cmp /dev/zero /dev/sdX
다음과 같은 출력이 나오는 경우:
cmp: EOF on /dev/sdX
드라이브가 0으로 채워져 있습니다.
% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo