수십만 개의 작은 파일로 인해 폴더가 다루기 어려워지는 문제가 있습니다.
수행 rm -rf하는 오류가 많은 파일이 있으며 대신 우리가해야 할 일은 다음과 같습니다.
find /path/to/folder -name "filenamestart*" -type f -exec rm -f {} \;
이것은 작동하지만 매우 느리고 메모리 부족으로 끊임없이 실패합니다.
더 좋은 방법이 있습니까? 이상적으로는 내용을 신경 쓰지 않고 전체 디렉토리를 제거하고 싶습니다.
답변
rsync를 사용하는 것은 빠르고 간단합니다.
mkdir empty_dir
rsync -a --delete empty_dir/ yourdirectory/
@sarath의 대답은 또 다른 빠른 선택을 언급했습니다 : Perl! 벤치 마크가보다 빠릅니다 rsync -a --delete.
cd yourdirectory
perl -e 'for(<*>){((stat)[9]<(unlink))}'
출처 :
답변
트위터의 누군가가 -delete대신 사용 을 제안했습니다.-exec rm -f{} \;
이것은 명령의 효율성을 향상 시켰지만 여전히 재귀를 사용하여 모든 것을 통과합니다.
답변
다음과 같은 것은 어떻습니까?
find /path/to/folder -name "filenamestart*" -type f -print0 | xargs -0rn 20 rm -f
parameter의 인수를 변경하여 한 번에 삭제할 파일 수를 제한 할 수 있습니다 -n. 공백이있는 파일 이름도 포함됩니다.
답변
영리한 속임수 :
rsync -a --delete empty/ your_folder/
슈퍼 CPU를 많이 사용하지만 실제로는 빠릅니다. https://web.archive.org/web/20130929001850/http://linuxnote.net/jianingy/en/linux/a-fast-way-to-remove-huge-number-of-files.html을 참조 하십시오
답변
의견 중 하나를 확장하면, 당신이 생각하는 것을하고 있다고 생각하지 않습니다.
먼저 상황을 시뮬레이션하기 위해 엄청난 양의 파일을 만들었습니다.
$ mkdir foo
$ cd foo/
$ for X in $(seq 1 1000);do touch {1..1000}_$X; done
그런 다음 내가 실패 할 것으로 예상 한 것과 시도했던 것처럼 들었습니다.
$ rm -r foo/*
bash: /bin/rm: Argument list too long
그러나 이것은 효과 가 있습니다.
$ rm -r foo/
$ ls foo
ls: cannot access foo: No such file or directory
답변
나는 테스트 할 기회가 있었다 -delete비교를 -exec rm \{\} \;나를 위해 -delete이 문제에 대한 답이었다.
를 사용 -delete하면 파일보다 최소 1,000 배 빠른 400,000 개 파일 폴더에서 파일을 삭제했습니다 rm.
‘리눅스에서 많은 수의 파일을 삭제하는 방법’기사는 약 3 배 빠르지 만 내 테스트에서는 그 차이가 훨씬 극적이라고 제안합니다.
답변
-delete위 의 옵션 정보 : 나는 그것을 사용하여 임시 폴더에서 많은 (1M + est) 파일을 제거하고 실수로 밤에 정리하는 것을 잊었습니다. 디스크 / 파티션을 실수로 채웠으므로 find .명령 외에는 제거 할 수있는 것이 없습니다 . 처음에는 내가 사용하는 것이 느립니다.
find . -ls -exec rm {} \;
그러나 그것은 극단적 인 시간이 걸렸습니다. 약 15 분 후에 일부 파일을 제거하기 시작했지만 마침내 시작된 후 초당 10 개 이하로 제거되고 있다고 생각합니다. 그래서 나는 다음을 시도했다.
find . -delete
대신, 지금 당장 실행 시키도록하겠습니다. 다른 명령이 아닌 CPU에 과도하게 부담을 주지만 더 빠르게 실행되는 것으로 보입니다. 지금은 한 시간 동안 실행 중이며 드라이브에서 공간을 다시 확보하고 파티션이 점차 “감소”하지만 여전히 오랜 시간이 걸립니다. 나는 그것이 다른 것보다 1,000 배 빠르게 실행되는지 의심합니다. 모든 것에서와 같이, 나는 공간 대 시간의 절충점을 지적하고 싶었습니다. 여분의 CPU 대역폭이 있다면 (우리는) 후자를 실행하십시오. CPU가 실행 중입니다 ( uptime보고서).
10:59:17 up 539 days, 21:21, 3 users, load average: 22.98, 24.10, 22.87
그리고로드 평균이 30.00 이상으로 바쁜 시스템에는 좋지 않지만 일반적으로 약간로드 된 시스템에 대해서는 2 시간 동안 괜찮습니다. 나는 시스템에서 대부분의 다른 것들을 점검했으며 여전히 반응이 있으므로 지금은 괜찮습니다.