이름으로 파일을 삭제하는 것이 고통스럽고 느리게 빠른 이유는 무엇입니까?

가짜 pas : 아래에 언급 한 "빠른"방법은 느린 방법보다 60 배 빠르지 않습니다. 30 배 더 빠릅니다. 나는 시간에 실수를 비난 할 것이다 (3AM은 명확한 사고를위한 나의 최고의 시간이 아니다).

업데이트 : 테스트 시간 요약을 추가했습니다 (아래).
속도 계수와 관련된 두 가지 문제가있는 것 같습니다.

• 사용 된 명령 선택 (아래에 표시된 시간 비교)
• 디렉토리에있는 많은 수의 파일의 본질 ... "큰 것이 나쁘다". 숫자가 증가함에 따라 상황이 불완전하게 느려집니다.

모든 테스트는 백만 개의 파일로 수행되었습니다.
(실제, 사용자 및 시스템 시간은
테스트 스크립트에 있습니다.) 테스트 스크립트는 paste.ubuntu.com 에서 찾을 수 있습니다.

#
# 1 million files           
# ===============
#
#  |time   |new dir   |Files added in  ASCENDING order  
#  +----   +-------   +------------------------------------------------- 
#   real    01m 33s    Add files only (ASCENDING order) ...just for ref.
#   real    02m 04s    Add files, and make 'rm' source (ASCENDING order) 
#                      Add files, and make 'rm' source (DESCENDING order) 
#   real    00m 01s    Count of filenames
#   real    00m 01s    List of filenames, one per line
#   ----    -------    ------
#   real    01m 34s    'rm -rf dir'
#   real    01m 33s    'rm filename' via rm1000filesPerCall   (1000 files per 'rm' call)
#   real    01m 40s    'rm filename' via  ASCENDING algorithm (1000 files per 'rm' call)
#   real    01m 46s    'rm filename' via DESCENDING algorithm (1000 files per 'rm' call)
#   real    21m 14s    'rm -r dir'
#   real    21m 27s    'find  dir -name "hello*" -print0 | xargs -0 -n 1000 rm'
#   real    21m 56s    'find  dir -name "hello*" -delete'
#   real    23m 09s    'find  dir -name "hello*" -print0 | xargs -0 -P 0 rm'
#   real    39m 44s    'rm filename' (one file per rm call) ASCENDING
#   real    47m 26s    'rm filename' (one file per rm call) UNSORTED
#                                                       

나는 최근에 생성 및 삭제 (10 개) 만 달러 빈 테스트 파일을. 이름을 기준으로 이름으로 파일을 삭제하면 (즉, rm filename), 두 가지 방법 사이에 큰 시간 차이 가 있다는 어려운 방법을 발견했습니다 ...

두 방법 모두 정확히 같은 rm filename명령을 사용합니다 .

업데이트 : 명령이 정확히 동일하지 않은 것으로 나타났습니다 ... 그중 하나는 한 번에 1000 개의 파일 이름을 'rm'에 보내고있었습니다 ... 각 파일 이름이 작성되었다고 생각했던 쉘 괄호 확장 문제였습니다. 피더 파일 자체에 한 줄이지 만 실제로는 한 줄에 1000 개였습니다.

파일 이름은 '피더 파일'을 통해 while read루프 로 제공됩니다
. 피더 파일은 다음의 출력입니다 ls -1 -f
. 메소드는 한 가지를 제외하고 모든 측면에서 동일합니다.

• 느린 방법에서 직접 정렬되지 않은 피더 파일을 사용하여ls -1 -f
• 빠른 방법은 같은 정렬되지 않은 파일의 정렬 된 버전을 사용합니다

정렬이 여기에서 문제인지 확실하지 않거나 정렬 된 피더 파일이 파일이 생성 된 순서와 일치하는 것일 수 있습니다 (간단한 오름차순 정수 알고리즘을 사용했습니다)

1 백만 파일의 경우 빠른 rm filename 방법이 느린 방법 보다 60 배 빠릅니다 ... 다시 말해서 이것이 "정렬"문제인지 또는 무대 뒤 해시 테이블 문제인지 모르겠습니다 ... 왜 의도적으로 나에게 새로 추가 된 "정렬 된"파일 이름 시퀀스의 정렬 되지 않은 목록을 제공 하기 때문에 단순한 정렬 문제는 아닙니다 . ls -1 -f

나는 여기에서 무슨 일이 일어나고 있는지 궁금해하고 있습니다. 그래서 다음 천만 개의 파일을 삭제하는 데 며칠이 걸리지 않습니다 (예 : 며칠이 걸리지 않습니다). 난 단지 테스트했습니다 있도록 numberof 파일에 disproportionatly 번 참여 증가 .. 참여 1 자세하게 만

BTW : 실제로보다 빠른 이름의 "정렬 된 목록"을 통해 파일입니다 삭제 rm -rf2. 배
와 : rm -r한 30 배 느린을 "정렬 된 목록"방법보다

...하지만 여기서 문제가 "분류"되었습니까? 또는 ext4에서 사용하는 해시 (또는 다른) 저장 방법과 관련이 있습니까?

나를 당황스럽게하는 것은 각각의 호출 rm filename이 이전 호출 과 관련이 없다는 것입니다. (적어도 'bash'관점에서 그런 식입니다)

Ubuntu / bash / 'ext4'/ SATA II 드라이브를 사용하고 있습니다.

rm -r은 재귀 적이므로 느릴 것으로 예상됩니다. 디렉토리 구조에서 깊이 우선 순회를 수행해야합니다.

이제 어떻게 천만 개의 파일을 만들었습니까? 어떤 순서로 반복되는 스크립트를 사용 했습니까? 1.txt, 2.txt, 3.txt ... 그렇다면 파일이 hdd의 연속 블록에 동일한 순서로 할당 될 수 있으므로 동일한 순서로 삭제하는 것이 더 빠릅니다.

"ls -f"는 -aU를 활성화하여 디렉토리 순서로 다시 재귀합니다.

파일 구조를 최적화해야합니다. 그래서 대신

for i in $(seq 1 1000); do touch file.$i; done

더 똑똑한 일을하십시오 (bash 가정) :

function bucklocate() 
{ 
    hash=$(echo -n "$1"|md5sum|cut -f1); 
    echo -n "${hash:1:1}/${hash:7:1}/${hash:9:2}/$1"; 
}

hexdig="{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f}"
eval mkdir -p $hexdig/$hexdig/$hexdig$hexdig


for i in $(seq 1 1000); do touch $(bucklocate file.$i); done

이제이 예제는 md5sum [1]을 사용하기 때문에 속도가 느립니다. 특정 파일 이름이 필요하지 않고 중복이 걱정되지 않고 다음과 같은 경우가 훨씬 빠릅니다. 특정 이름의 반복 가능한 해시 :)

mkdir -pv {0,1,2,3,4,5,6}/{0,1,2,3,4,5,6,7,8,9,10,12}
for  a in $(seq 1 100); do i=$RANDOM; echo touch "$(($i%7))/$(($i%13))/file.$i"; done

물론 이것은 해시 테이블에서 모두 빌려주는 개념입니다.