파일이 50Gb 인 외부 저장 드라이브 (USB 연결, 유형 fuseblk)에서 rm이 ​​느린 이유는 무엇입니까?


21

백업 을 위해 rsnapshot 을 사용하려고 했지만 사용할 수없는 것으로 나타났습니다 . 디렉토리 (50gb)를 diff하고 몇 분 안에 복제 (모든 파일을 하드 링크) 할 수 있지만 약 30 분 안에 전체 디렉토리를 cp 할 수는 있지만 삭제하는 데 1 시간 이상이 걸립니다. 을 직접 사용하더라도 rm -rfv단일 파일을 작성하는 데 최대 0.5 초가 걸리는 반면 cpand link명령은 즉시 완료됩니다.

rm이 왜 이렇게 느린가요? 하드 링크를 재귀 적으로 제거하는 더 빠른 방법이 있습니까? 파일을 복사하는 것이 파일을 제거하는 것보다 시간이 덜 걸린다는 것은 말이되지 않습니다.

내가 작업중 인 파일 시스템은 usb를 통해 연결되고 fuseblk 유형 (ntfs라고 생각합니다)을 통해 연결된 외부 저장 장치 드라이브입니다. 내 컴퓨터는 우분투 리눅스를 실행하고 있습니다.

상단에서 출력 :

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

1
마운트 된 것은 fuseblk드라이브가 NTFS임을 의미하는 것이 아니라 단지 FUSE 블록 장치로 마운트되었음을 ​​의미합니다. 거의 모든 것이 될 수 있습니다.
Chris Down

1
@ChrisDown True이지만 NTFS 또는 ext3이라는 것을 알고 있으며 ext3이면 인수없이 마운트하여 마운트 될 것이라고 확신합니다.
Benubird

1
디렉토리에 몇 개의 파일이 있는지에 따라 (얼마나 많은 말을하지 않았는지), 특히 NTFS는 디렉토리에> 3K 파일 만 있으면 느려집니다. 거의 모든 다른 파일 시스템이 훨씬 더 성능이 좋습니다. 파일 시스템 성능에 대한 파일 수의 영향에 대한 SO / SE의 다른 많은 게시물을 모두보십시오.
smci

답변:


28

궁극적으로, 무엇을 하든지 부모 디렉토리 를 호출하더라도 제거하려는 모든 단일 파일 rm에서 실행 unlink되어야합니다 rm -r. 제거 할 파일이 많은 경우 시간이 오래 걸릴 수 있습니다.

실행할 때 특히 시간이 많이 걸리는 두 가지 프로세스가 있습니다 rm -r.

  1. readdir다음에
  2. 에 대한 여러 번의 호출 unlink.

모든 파일을 찾은 다음 모든 단일 파일을 제거하여 제거하는 데 시간이 오래 걸릴 수 있습니다.

디렉토리를 일정 시간 동안 사용할 수 없기 때문에이 "사용할 수 없음"을 발견 한 경우, 제거하기 전에 상위 디렉토리를 이동하는 것이 좋습니다. 이렇게하면 시간이 너무 많이 걸리지 않고 프로그램에서 다시 사용할 수 있도록 해당 이름이 비워집니다.

파일 시스템이 정말 있다고 가정 입니다 NTFS (이 질문에서 불분명), NTFS 파일의 큰 붕대를 삭제에서 매우 느린 일반적입니다. 목적에보다 적합한 파일 시스템을 사용하는 것을 고려할 수 있습니다 (다른 특정 요구 사항이없는 경우 최신 ext 파일 시스템은 삭제 성능이 상당히 좋습니다). 퓨즈 자체도 일반적으로 빠르지는 않습니다. FUSE를 사용하지 않는 방식으로이 작업을 수행 할 수 있는지 확인하는 것이 좋습니다.


2
+1 실제로 많은 부분이 정확한 파일 시스템에 달려 있습니다. 많은 사람들이 다른 작업에서는 느리면서도 일부 작업에서는 실제로 잘 수행하는 경향이 있습니다 (종종 파일 생성 대 제거 대 데이터 액세스).
peterph

15

rm이 왜 이렇게 느린가요? 나도 몰라 그러나 나는 더 빠른 방법을 알고 있습니다.

mkdir blank
rsync -a --delete blank/ test/

업데이트 : Serverfault에 대한이 답변 에는 몇 가지 설명이 있습니다. rsync가 파일 시스템 트리의 균형을 유지하고 재조정이 필요하지 않은 특정 순서로 파일을 삭제하는 것처럼 보입니다. rm은 파일을 삭제하고 제거 될 때 많은 재조정을 일으 킵니다. 여기 에 재조정에 대한 정보가 있습니다 .


1
이것을 벤치마킹하고 비교 했습니까 rm -rf? rsync여전히의 unlink()모든 파일에 test/있어야하며 아마도 시간이 걸리는 것일 수 있습니다.
MattBianco

공식적으로 벤치마킹하지는 않았지만 다른 사람의 벤치 마크를 읽은 후에 시도했지만 그 차이는 상당했습니다. 그 게시물을 더 이상 찾을 수 없지만 serverfault에 대한 이 답변 에는 더 빠른 삭제 프로그램에 대한 설명과 소스가 있습니다.
rjmunro

그러나 가장 빠른 방법은 unlink(2)디렉토리에 있어야하며 fsck나중에 기억해야합니다 ...
MattBianco

사실은 사실입니다. 시간을 정하면 거의 두 배나 빠릅니다. GNU coreutils rm 코드를 읽은 후에도 궁금하지 않습니다…
Dominik George

1

글쎄, 나는 당신과 비슷한 문제가있었습니다. 당신의 "wa"가 높다는 것을 알았습니다.

iostat -x 1

디스크 사용률이 높은지 확인하려면 디스크 사용량이 많음을 의미합니다. 다른 프로세스가 디스크에 지속적으로 쓰고 있는지 확인하십시오 .

단순화를 위해

vmstat 1

b 가 높거나 r < b 인지 확인합니다 . 그것은 뭔가 잘못되었음을 나타냅니다. 귀하의 상황에서는 디스크 io가 원래의 이유라고 생각합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.