8GB 드라이브에서 dd를 실행하는 데 시간이 오래 걸리는 이유

8GB 드라이브에서 dd를 실행하는 데 시간이 오래 걸리는 이유

약 8GB의 ZFS에서 처리하는 파일 시스템이 있습니다.

다음 명령을 실행하여 파일 시스템을 제로화해 보았습니다.

dd if=/dev/zero of=/EMPTY bs=1M | true
rm -f /EMPTY

일반적으로 ext4 파일 시스템에서는 몇 초 안에 완료됩니다.

그러나 이번에는 계속 진행되었습니다.

두 번째 터미널을 실행하고 그 크기를 확인할 수 있습니다 /EMPTY. 실행 후 ll -h디스플레이 /EMPTY는 800GB입니다! 8GB에는 800GB가 적합하지 않은 것 같습니다.

또한 이를 실행하면 df -h파일 시스템이 채워지지 않고 있음을 알 수 있습니다.

그러나 dd는 CPU의 50%를 소비하고 노트북을 뜨겁게 만듭니다. 나는 그것이 많은 일을 하지만 아무것도 얻지 못한다고 가정합니다.

그렇다면 dd가 영원히 실행되고 크기를 전혀 차지하지 않는 파일을 생성하는 이유는 무엇입니까? ext4에서는 완료되어야 하며 계속할 수 있도록 오류가 발생합니다.

답변1

나는 당신이 달성하려는 것이 무엇인지 모르므로 명령이 실제로 수행하는 작업만 설명할 수 있습니다.

dd if=/dev/zero

무제한의 0(또는 NUL) 바이트를 반환하는 특수 장치에서 데이터를 읽고 있습니다.

of=/EMPTY

위의 (무제한) 입력으로 새 파일을 생성합니다.

bs=1M

메가바이트 단위로 데이터 스트림을 무제한으로 읽고 쓸 수 있습니다. 파일 시스템을 가득 채울 수 있고 많은 도구가 이를 처리할 수 없기 때문에 이와 같은 작업을 수행해서는 안 됩니다. 하지만외부 4파일 시스템이 효과적으로 채워지고 명령이 종료되며, 압축된 파일 시스템은 0바이트 스트림을 적극적으로 압축할 수 있습니다.

| true

ddwith는 of=어떤 출력도 생성하지 않기 때문에 이는 말도 안되는 소리입니다 . || true상태 코드를 무력화하려고 할 수도 있지만 dd단일 명령 실패로 인해 전체 스크립트가 종료되지는 않으므로 이는 별로 유용하지 않습니다.

일반적인 용도는 dd if=/dev/zero전체 장치를 0으로 설정하는 것입니다 /dev/sdb. 예를 들어 다른 답변에서 언급했듯이 shred. 두 경우 모두 개별 파일(더 이상 존재하지 않을 수 있음)이 아닌 블록 장치로 시스템에 나타나는 전체 시스템 파티션을 참조하려고 합니다. Linux 블록 장치와 매뉴얼 페이지에 관한 많은 책과 온라인 리소스가 있으며, 이들 shred역시 dd매우 유용합니다.

파일을 삭제하면 해당 블록을 즉시 사용할 수 있습니다. 흑마술을 할 필요는 없습니다. 포렌식 기법을 방지하기 위해 파일 내용을 지우려면 schred --delete일반 삭제 대신 파일 삭제를 사용하면 됩니다. 삭제된 파일의 블록을 지우는 것은 그리 쉬운 일이 아니며 단순히 큰 빈 파일을 생성하는 데에만 의존할 수는 없습니다. 이 작업을 안전하게 수행하려면 전문적인 파일 시스템별 도구가 필요합니다.

답변2

ZFS에 압축 문제가 발생했습니다. 파일 시스템을 지우려고 하면 ZFS에서는 그렇게 할 수 없습니다. 기본 디스크를 지우려는 경우 가장 좋은 방법은 zfs 풀에서 "zpool destroy"를 사용한 다음 물리적 장치 자체에서 dd를 사용하는 것입니다. ("dd if=/dev/zero of=/dev/...."). 완료되면 zpool create를 사용하여 풀을 다시 생성하면 됩니다.

답변3

잘 모르겠지만 ZFS파일 시스템을 제로화하는 것이 목적이라면 dd다음을 제안하겠습니다. 조각조각 찢다

dd가 무한 루프에 있는 이유에 대한 답은 없지만 최종 목표는 해결되었습니다.

관련 정보