저는 Linux 클러스터에 액세스 할 수있는 전산 화학 대학원생입니다. 클러스터는 수십 개의 컴퓨팅 노드가 연결된 매우 큰 (25TB) 파일 서버로 구성됩니다. 각 컴퓨팅 노드는 8 ~ 24 개의 Intel Xeon 코어로 구성됩니다. 각 컴퓨팅 노드에는 약 365TB의 로컬 디스크도 포함됩니다.
파일 서버는 리서치 그룹의 12 명 정도의 사용자가 일상적으로 액세스하므로, 파일 서버는 주로 장기 파일 저장에 사용됩니다 (이는 야간에 백업되는 반면 컴퓨팅 노드의 로컬 디스크는 백업되지 않음). 따라서 시스템 관리자는 파일 서버보다 I / O가 빠른 로컬 디스크에서 시뮬레이션을 실행하여 다른 사용자의 파일 서버 속도를 늦추지 않도록 지시했습니다.
따라서 로컬 디스크에서 시뮬레이션을 실행 한 다음 완료된 후 궤적 파일 (MD) 시뮬레이션을 실행하는 파일을 파일 서버에 복사하여 저장합니다. traj.trr
노드의 로컬 디스크에있는 디렉토리에 궤적 파일이 있다고 가정 합니다 /home/myusername/mysimulation1/traj.trr
. 장기 저장을 위해 항상 traj.trr
파일 서버의 디렉토리에 복사 합니다. ~/mysimulation1/traj.trr
여기서 파일 서버의 ~
내 디렉토리를 나타냅니다 /export/home/myusername
. 그것을 복사 한 후, 나는 습관적으로 사용 du -h
하여 /home/myusername/mysimulation1/traj.trr
파일 크기가 같은지 확인합니다 ~/mysimulation1/traj.trr
. 이렇게하면 적어도 파일 서버로 성공적으로 전송되었음을 확신 할 수 있습니다. 예를 들면 다음과 같습니다.
cd /home/myusername/mysimulation1/
cp -v traj.trr ~/mysimulation1/
du /home/myusername/mysimulation1/traj.trr -h
du ~/mysimulation1/traj.trr -h
du -h
사람이 읽을 수있는 동일한 파일 크기 를 제공 하기 위해 두 번 호출 하면 전송 / 복사에 성공한 것으로 합리적으로 확신 할 수 있습니다. ( traj.trr
내가 실행 한 정확한 시뮬레이션에 따라 일반적인 파일 크기는 약 15 ~ 20GB입니다.) 두 파일에서 실행하는 경우 du
(예 : -h
스위치 없이 ) traj.trr
바이트 단위의 크기는 일반적으로 매우 유사합니다. -보통 몇 바이트 이내 나는 지난 1 년 반 동안이 전체적인 방법을 문제없이 사용해왔다.
그러나 최근에 다음과 같은 문제가 발생했습니다. 때로는du -h
두traj.trr
파일의 크기가 몇 GB가 다르다고보고합니다. 예를 들면 다음과 같습니다.
cd /home/myusername/mysimulation1/ # this is the local disk
cp -v traj.trr ~/mysimulation1/
du traj.trr -h
cd ~/mysimulation1/ # this is the fileserver
du traj.trr -h
두 호출의 출력은 du -h
각각 다음과 같습니다.
20G traj.trr
28G traj.trr
시뮬레이션 궤적이 각각 약 15 ~ 20GB이기 때문에 전자 (예 : traj.trr
로컬 디스크 /home/myusername/mysimulation1/
)는 올바른 파일 크기라고 생각합니다. 그러나 파일 서버의 파일이 실제로 어떻게 더 클 수 있습니까? 어떻게 든 cp
전송이 실패 하면 어떻게 더 작을 수 있는지 알 수 있습니다 . 그러나 실제로 어떻게 더 클 수 있는지 알 수 없습니다 .
위와 동일한 명령을 실행할 때 비슷한 출력을 얻지 만 -h
스위치가 주어지지 않았습니다 du
.
20717480 traj.trr
28666688 traj.trr
차이가 나는 이유를 생각할 수 있습니까?
만일 우연히도 du
오작동을한다면 괜찮습니다. 그러나 traj.trr
파일 서버 의 사본 이 완전하고 로컬 디스크의 소스 버전과 동일해야합니다. 새 시뮬레이션을 실행하기에 충분한 로컬 디스크 공간이 있도록 로컬 파일을 삭제해야하지만 traj.trr
파일 서버 의 버전 이 손상 될 수는 없습니다 .
Gromacs 분자 역학 패키지 의 .trr 파일 형식 은 텍스트가 아닌 이진 형식입니다. 따라서와 같은 프로그램에서 파일을 안정적으로 비교할 수 있는지 확실하지 않습니다 diff
.
답변
무결성을 확인하기 위해 md5sum
또는 같은 것을 사용해야 sha1sum
합니다.
실제로 크기를 사용하려면 ls -l
또는 을 사용하십시오 du -b
.
이 du
유틸리티는 일반적으로 파일의 디스크 사용량, 즉 파일 시스템에서 사용하는 파일 시스템의 양만 표시합니다. 이 값은 백업 파일 시스템 및 스파 스 파일과 같은 다른 요소에 따라 달라집니다.
예:
$ truncate -s 512M foo
$ cat foo >bar
$ ls -l foo bar
-rw-r--r-- 1 michas users 536870912 23. Dez 00:06 bar
-rw-r--r-- 1 michas users 536870912 23. Dez 00:03 foo
$ du foo bar
0 foo
524288 bar
$ du -b foo bar
536870912 foo
536870912 bar
512MB의 0을 포함하는 두 개의 파일이 있습니다. 첫 번째는 드문 드문 저장되고 디스크 공간을 사용하지 않는 반면, 두 번째는 각 바이트를 디스크에 명시 적으로 저장합니다. -파일은 동일하지만 디스크 사용량이 완전히 다릅니다.
이 -b
옵션은 당신에게 좋을 것입니다 :
-b, --bytes
equivalent to '--apparent-size --block-size=1'
--apparent-size
print apparent sizes, rather than disk usage; although the apparent
size is usually smaller, it may be larger due to holes in
('sparse') files, internal fragmentation, indirect blocks, and the
like
답변
동일한 데이터를 2 개의 다른 HDD에 넣을 때 발생하는 일반적인 문제입니다. du
리눅스 노드라고 가정하면 추가 스위치와 함께 명령 을 실행하고 싶을 것 입니다.
스위치?
--apparent-size
print apparent sizes, rather than disk usage; although the
apparent size is usually smaller, it may be larger due to holes in
('sparse') files, internal fragmentation, indirect blocks, and the
like
예
$ du -sh --apparent-size /home/sam/scsconfig.log ~/scsconfig.log
93K /home/sam/scsconfig.log
93K /root/scsconfig.log
위의 파일 시스템은 로컬 디스크 ( /root
)이고 다른 파일 시스템은 /home/sam
내 NAS의 NFS 공유입니다.
$ df -h . /home/sam
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
222G 118G 92G 57% /
mulder:/export/raid1/home/sam
917G 566G 305G 65% /home/sam
무슨 일이야?
이것은 많은 사람들을 혼란스럽게하지만 파일이 디스크에 저장 될 때 해당 블록의 일부만 사용하더라도 공간 블록을 소비한다는 것을 기억하십시오. 당신이 du
없이 실행 --apparent-size
하면 파일이 소비하는 실제 공간이 아니라 사용 된 디스크의 블록 공간의 양에 따라 크기를 얻습니다.
대신 체크섬을 사용합니까?
2 개의 트리 파일을 비교할 경우이 방법이 더 좋습니다. 이 명령을 사용하여 모든 파일의 체크섬을 계산 한 다음 체크섬의 최종 체크섬을 계산할 수 있습니다. 이 예제는 사용 sha1sum
하지만 md5sum
대신 쉽게 사용할 수 있습니다 .
$ cd /some/dir
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
예
$ cd ~/dir1
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
55e2672f8d6fccff6d83f0bffba1b67aeab87911 -
$ cd ~/dir2
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
55e2672f8d6fccff6d83f0bffba1b67aeab87911 -
따라서 우리는 두 나무가 동일하다는 것을 알 수 있습니다.
(참고 : find 명령은 파일 시스템에 나타난대로 파일을 나열합니다. 따라서 다른 파일 시스템에서 두 개의 디렉토리 (예 : Ext3와 APFS)를 비교하는 경우 최종 sha1sum 전에 먼저 정렬해야합니다. 시안 준동)
답변
짧은 대답 : 파일 크기를 테스트하지 말고 명령의 반환 상태를 테스트하십시오. 반환 상태는 복사본의 성공 여부에 대한 신뢰할 수있는 유일한 표시입니다 (두 파일을 바이트 단위로 직접 간접적으로 비교하는 데 부족함-복사가 성공한 경우 중복 임).
파일 크기 확인은 복사 성공 여부를 확인하는 데 유용한 방법이 아닙니다. 경우에 따라 웹에서 파일을 다운로드 할 때 유용성 검사가 유용 할 수 있습니다. 그러나 여기 더 좋은 방법이 있습니다.
모든 Unix 명령은 성공 여부를 나타내는 상태를 반환합니다. 성공의 경우 0, 오류의 경우 1 이상. 따라서 종료 상태를 확인하십시오 cp
. cp
실패하면 일반적으로 오류 메시지를 인쇄하여 오류가 무엇인지 나타냅니다. 스크립트에서 마지막 명령의 종료 상태는 magic 변수에 $?
있습니다.
cp -v traj.trr ~/mysimulation1/
if [ $? -ne 0 ]; then
echo 1>&2 "cp failed due to the error above"
exit 2
fi
$?
0 인지 확인하는 대신 부울 연산자를 사용할 수 있습니다.
cp -v traj.trr ~/mysimulation1/ || exit 2
스크립트를 실행 중이고 명령이 실패하면 스크립트를 중지하려면을 실행하십시오 set -e
. 명령이 실패하면 (즉, 0이 아닌 상태를 반환) 스크립트는 명령과 동일한 상태로 즉시 종료됩니다.
set -e
…
cp -v traj.trr ~/mysimulation1/
복사 한 파일이 더 큰 이유는 드문 파일 이기 때문 입니다. 스파 스 파일은 널 바이트 만 포함하는 블록이 저장되지 않는 조잡한 압축 형식입니다. 파일을 복사 할 때 cp
명령은 널 바이트를 읽고 쓰므로 원본에 누락 된 블록이있는 경우 사본에는 널 바이트로 가득 찬 블록이 있습니다. Linux cp
에서이 명령은 스파 스 파일을 탐지하려고 시도하지만 항상 성공하지는 않습니다. cp --sparse=always
CPU 시간이 약간 증가하여 더 열심히 시도합니다.
더 일반적으로 du
다른 압축 형식으로 인해 다른 결과를 반환 할 수 있습니다. 압축 파일 시스템은 드물다. 사용하는 디스크 블록 수와 달리 파일의 바이트 수와 같은 파일 크기를 알고 싶다면 ls -l
대신을 사용하십시오 du
.