파일을 제거하는 데 시간이 너무 오래 걸림

짧은 버전 : rm -rf mydir과 mydir(재귀 적으로), 250 만 파일을 포함하고는 대부분 유휴 컴퓨터에서 약 12 시간이 소요됩니다.

추가 정보 : 삭제되는 대부분의 파일은 다른 디렉토리에있는 파일에 대한 하드 링크입니다 (삭제되는 디렉토리는 실제로 가장 오래된 백업 rsnapshot이며 rm명령은 실제로에 의해 제공됨 rsnapshot). 따라서 대부분 디렉토리 항목이 삭제됩니다. 파일 내용 자체는 그리 많지 않습니다. 약 10GB 정도입니다.

나는 그것이 btrfs범인 이라는 사실과 는 거리가 멀다 . 백업을 사용하기 전에 백업 속도가 매우 느리다는 것을 기억 btrfs하지만 속도가 느리게 삭제되었는지는 확실하지 않습니다.

머신은 4GB RAM의 Intel Core i5 2.67GHz입니다. 여기에는 2 개의 SATA 디스크가 있습니다. 하나에는 OS와 다른 것들이 있으며 백업 디스크는 1TB WDC WD1002FAEX-00Z3A0입니다. 마더 보드는 Asus P7P55D입니다.

편집 : 기계는 리눅스와 데비안 wheezy입니다 3.16.3-2~bpo70+1. 파일 시스템이 마운트되는 방식입니다.

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

편집 : 사용하는 rsync -a --delete /some/empty/dir mydir데 약 6 시간이 걸립니다. 에 비해 크게 개선 rm -rf되었지만 여전히 너무 많이 생각합니다. ( 이유 rsync가 더 빠른 이유에 대한 설명rm : "[M] 대부분의 파일 시스템은 디렉토리 구조를 btree 형식으로 저장합니다. 파일을 삭제하는 순서는 중요합니다. 링크 해제를 수행 할 때 btree의 균형을 다시 잡는 것을 피해야합니다. .... rsync -a --delete... 삭제 순서대로 ")

편집 : 220 만 개의 파일이있는 다른 디스크를 디렉토리에, 그러나 XFS에 연결했습니다. 비교 결과는 다음과 같습니다.

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] hdparm -T /dev/sdX및 hdparm -t /dev/sdX.
[2] find mydir -print|wc -l부팅 후 즉시 실행하는 데 걸린 시간 입니다.
[3] XFS 디스크에서 find. BTRFS 디스크에서 이것은 오래된 측정입니다 (트리가 캐시 된 것으로 생각하지 않습니다).

에 문제가있는 것 같습니다 btrfs.

linux btrfs

— 안토니스 크리스토 피데스
소스

단일 디렉토리에 250 만 개의 파일이 있습니까? 나는 이것을 잘 처리하는 파일 시스템을 모른다.

— Michael Hampton

@ MichaelHampton : 평평하지 않고 중첩 된 디렉토리가 포함되어 있습니다. 간단한 설명에서 "재귀 적으로"라는 단어를 추가했습니다. 이것이 명확 해지기를 바랍니다.

— Antonis Christofides

copy-on-write 파일 시스템에서 copy-on-write 디렉토리 트릭을 사용하는 이유는 무엇입니까?

— symcbean

@symcbean : 하드 링크 트릭이 중복되어 있음을 의미 btrfs합니까? 물론 가능하지만 관련성이 있다고 생각하십니까? 지금 시도한 이유를 기억할 수 없습니다 btrfs.

— Antonis Christofides

아, 기억 나 btrfs투명 압축을 원했기 때문에 로 전환하기로 결정했습니다 . 지금 : rsnapshot하드 링크를 사용합니다. 하드 링크를 사용하지 않는 옵션은 없습니다. 따라서 하드 링크는 btrfs의 기록 중 복사 기능 과 겹치지 만 그에 대해서는별로 할 수 없습니다.

— Antonis Christofides

답변:

글쎄, 이것은 여전히 Btrfs 문제이며, 많은 작은 파일을 삭제하면 다른 파일 시스템에 비해 시간이 오래 걸린다는 사실이 잘 알려져 있습니다.

마음에 들지 않으면 업스트림에서 수정 될 때까지 기다리거나 더 잘 수행하는 다른 파일 시스템으로 이동할 수 있습니다.

주요 오류는 btrfs와 함께 고대 커널 (3.16, 예 게시했을 때 이미 고대)을 사용하는 것입니다. Btrfs는 여전히 대량 개발중인 파일 시스템이므로 항상 최신 및 최고의 커널 버전을 유지하여 개선 사항을 확인해야합니다. 배포판이 백 포트를 수행하지 않으면 직접 수행하거나 망할 수 있습니다.

Btrfs는 커널 버전 3.19에서 많은 성능 향상을 얻었습니다. 이것은 프로덕션에서 사용해야하는 최소 버전이며 커널 버전 3.16은 백 포트없이 빠릅니다.

또한 크리스 메이슨 (Chris Mason)에 따르면 현재 Btrfs는 안정적이지만 아직 생산 준비가되지 않았다는 점을 명심하십시오.

— 마크 스터 머
소스

"잘 알려진"을 어떻게 정의합니까? 나는 웹을 광범위하고 헛된 것으로 검색했으며,이 토론에 참여한 사람들 중 누구도 웹을 알지 못했습니다. 그러나 어쨌든, 나는 지금 막 떠나고 있습니다 btrfs. 그것의 개발이 영원히 걸리는 것처럼 너무 과대 광고.

— Antonis Christofides

글쎄, 예를 들어 CoreOS의 사람들이 있습니다. 2015 년 초까지 Ext4 + Overlayfs로 전환 한 2015 년까지 기본 파일 시스템으로 1 년 정도 Btrfs를 사용했습니다. 이것은 커널 버전 3.19 이전에 있었으므로 Btrfs가 많이 향상되었습니다. 또한 데이터베이스 작업로드 조건에 대한 ext4, xfs, zfs 및 btrfs (Postgres : de.slideshare.net/fuzzycz/)를 살펴 보는 2015 년 10 월 프레젠테이션을 살펴보십시오. 또 다른 벤치 마크는 좋지 않습니다. goo.gl/rR3kZ2

— Marc Stürmer

그리고 내가 말했듯이, 박스의 커널 버전 (3.16)은 성능 문제로 괴롭히는 것으로 알려져 있습니다 .Chris Mason에 따르면 심각한 Btrfs 항목에는 적어도 3.19를 사용하십시오. Btrfs를 진지하게 사용하고 싶다면 항상 데비안에서는 잘 작동하지 않는 최신 커널을 사용하십시오. 검색어 "btrfs 메타 데이터 성능"

— Marc Stürmer

이 파티에 약간 늦었지만 다음은 매우 큰 btrfs 트리를 매우 빠르게 삭제하는 요령입니다.

동일한 btrfs 파일 시스템에 더미 서브 볼륨을 작성하십시오.
제거하려는 최상위 디렉토리를 해당 하위 볼륨으로 이동하십시오. 하위 볼륨에서도 동일한 btrfs 파일 시스템에서이 작업을 수행하면이 작업이 매우 빠릅니다.
하위 볼륨을 삭제하십시오.

커널은 백그라운드에서 공간을 되찾기 시작하므로 사용 가능한 공간이 즉시 확보되지는 않지만 프로세스는 사용자 영역 삭제를 수행하는 것보다 훨씬 빠릅니다.

— 니콜라스 노블
소스

디렉토리 이름을 바꾼 다음 백그라운드 프로세스에서 이름이 바뀐 디렉토리를 삭제할 수 있습니다. 삭제 작업 속도가 빨라지지 않습니다. 그러나 이렇게하면 삭제 조작이 수행되는 동안 프로그램이 빈 디렉토리로 계속 진행할 수 있습니다.

이것이 귀하의 유스 케이스에서 작동하는지 확실하지 않습니다. 디스크가 유휴 상태가 될 때까지 프로그램을 계속 진행할 수 없는지 여부에 따라 다릅니다 (즉, 디스크 작업이 심할 경우). 프로그램이 디스크에 많은 데이터를 채울지 여부에 달려 있습니다.

— 나단
소스