제대로 테스트되지 않은 프로그램이 NFS 공유에 엄청난 수의 파일이 포함된 디렉터리를 생성했는데, 이를 제거해야 합니다.
ls -ald /home/foo
drwxrwxr-x 2 503 503 317582336 Jul 29 11:38 /home/foo
디렉토리는 netapp 유형 장치에서 약 600GB의 NFS 마운트에 있습니다. 실제로 그 안에 얼마나 많은 파일이 있는지는 모르지만 단 10분 후에 생성된 유사한 디렉토리에는 121,000개의 파일이 있으므로 어딘가에 수백만 개에 달할 것입니다. OS는 Linux 2.6 커널입니다.
그것과 그 내용을 나열하거나 제거하는 방법을 찾으려고 노력하고 있습니다. find /home/foo 결과는 "./" 이외의 출력 없이 약 1시간 후에 find 종료됩니다.
답변1
(누군가 비슷한 것을 검색하는 동안 그것을 발견할 경우를 대비해 내 자신의 질문에 대답합니다.) 디렉토리에는 최대 900만 개의 파일이 있을 수 있습니다.
안타깝게도 서버에 직접 로그인할 수 없습니다. 이는 어플라이언스입니다. 파일 시스템에 대한 유일한 액세스는 내보내기를 통해서입니다.
rm -rf가 작동하지 않는 것 같습니다. strace로 보면서 그것은 매달려 있었다.
find가 완료되지 않아 오류 없이 종료되었습니다.
ls -1이 완료되지 않은 것 같습니다. (이제 결과를 정렬하려고 시도한다는 것을 깨달았습니다. ls -1f는 결국 작동했을 수도 있습니다).
작동한 것은 간단한 Perl 조각이었습니다. 나는 C 코드가 동일하게 작동한다고 가정합니다.
opendir( my $dh, '/home/foo' ) or die $!
while ( my $file = readdir $dh ) {
print "$file\n";
}
답변2
다소 오래된 스레드가 Google에 올라왔으므로 몇 가지 통계를 공유하고 싶습니다.
다음은 NFS 서버에서 파일을 제거하는 세 가지 방법을 비교한 것입니다.
- 일반 RM:
rm dir/* - 찾다:
find dir/ -type f -exec rm {} \; - 재동기화:
tempdir=$( mktemp -d ); \ rsync -a --delete $tempdir/ dir/; \ rmdir $tempdir
이러한 방법을 비교하기 위해 테스트를 실행할 때마다 10000개의 파일을 만들었습니다.
for i in {1..10000} ; do touch $i ; done
플롯의 결과는 rsync가 훨씬 빠르며 find가 세 가지 방법 중 가장 느린 것을 보여줍니다.
파일 수가 두 배로 늘어나고( find20000개 파일을 실행하지 않음) 결과는 유지되며, 평균 시간은 10000개 파일에 대해 3회 실행, 20000개 파일에 대해 2회 실행입니다.
10000 20000
find 28.3 -
rm 12.9 23.9
rsync 6.94 12.2
이러한 방법의 성능이 또 무엇에 의존하는지 보는 것은 흥미롭습니다.
관련우편이 사이트에서는 ext3 파일 시스템에서 많은 수의 파일을 삭제하는 방법에 대해 설명합니다.
답변3
NFS를 통해 이러한 파일을 제거하지 않는 것이 좋습니다. 파일 서버에 직접 로그인하여 파일을 삭제하세요. 이렇게 하면 NFS 서버(및 클라이언트)에 대한 공격이 훨씬 줄어듭니다.
그 외에도 ls -1 | xargs rm -ffind를 완료하는 데 문제가 있는 경우 find(MattBianco의 설명대로)를 사용하거나 해당 디렉토리 내에서 사용하십시오(후자는 NFS를 통해 제대로 작동하지만 다시 로컬에서 수행하는 것이 좋습니다).
답변4
이것은 조금 분명해 보이지만 다음을 시도해 보셨습니까?
rm -rf /home/foo/
? 실패하면 정규식을 사용하여 전달할 수 있을 만큼 작은 하위 집합을 얻을 수 있는 방법이 있습니까 |xargs rm?
ls가 실패하면 echo /home/foo/* | xargs rm'라인이 너무 길다' 등의 이유로 실패할 수도 있습니다. 아, 그리고 NFS 대신 서버에서 직접 이 작업을 수행하는 것이 좋습니다.