단일 디스크에서 가장 빠른 Linux 파일 시스템

회전식 드라이브에 상당한 관심이 있습니다. 이것들은 데이터 트랙을 너무 가깝게 배치하여 다음 트랙을 방해하지 않고 한 트랙에 쓸 수 없습니다. 이로 인해 용량이 20 % 정도 증가 할 수 있지만 쓰기 증폭 문제가 발생합니다. Shingled 드라이브에 최적화 된 파일 시스템에 대한 작업이 진행 중입니다 (예 : https://lwn.net/Articles/591782/ 참조).

Seagate 8TB 아카이브와 같은 일부 디스크에는 임의 쓰기를위한 캐시 영역이 있으므로 일반 파일 시스템에서 적절한 성능을 발휘할 수 있습니다. 디스크는 일부 일반 워크로드에서 최대 200MB / 초의 쓰기 속도로 매우 빠릅니다. 그러나 임의 쓰기 캐시가 오버 플로우되면 성능이 저하 될 수 있습니다. 아마도 일부 파일 시스템은 일반적으로 무작위 쓰기를 피하는 것이 더 좋거나 무작위 쓰기 패턴이 그러한 드라이브에서 발견되는 쓰기 캐시를 오버플로 할 가능성이 높습니다.

리눅스 커널의 주류 파일 시스템은 ext4보다 shingled disks의 성능 저하를 피하는 데 더 좋 습니까?

직관적으로 기록 중 복사 및 로그 구조 파일 시스템은 무작위 쓰기를 줄임으로써 대상 디스크의 성능을 향상시킬 수 있습니다. 벤치 마크는이를 약간 지원하지만 이러한 성능 차이는 대상 디스크에만 국한되지 않습니다. 또한 제어로 사용되는 분리되지 않은 디스크에서도 발생합니다. 따라서 대상 디스크로의 전환은 선택한 파일 시스템과 관련이 없을 수 있습니다.

nilfs2 파일 시스템은 SMR 디스크에서 상당히 우수한 성능을 제공했습니다. 그러나 이것은 전체 8TB 파티션을 할당했기 때문에 벤치 마크는 ~ 0.5TB 만 기록했기 때문에 nilfs 클리너를 실행할 필요가 없었습니다. 파티션을 200GB로 제한했을 때 nilfs 벤치 마크는 성공적으로 완료되지 않았습니다. "아카이브"디스크를 실제로 아카이브 디스크로 사용하여 모든 데이터와 스냅 샷을 디스크에 영원히 기록한 다음 nilfs 클리너를 실행할 필요가없는 경우 Nilfs2는 성능 측면에서 좋은 선택입니다.

ST8000AS0002-1NA17Z테스트에 사용한 8TB 씨게이트 드라이브의 캐시 영역 이 ~ 20GB 인 것으로 알고 있습니다. 벤치 마크 세트가 풀리지 않은 캐시 영역보다 ~ 125GB가되도록 기본 파일 벤치 파일 서버 설정을 변경했습니다.

set $meanfilesize=1310720
set $nfiles=100000
run 36000

이제 실제 데이터입니다. op의 수는 "전체"파일 서버 성능을 측정하는 반면 ms / op는 임의 추가의 대기 시간을 측정하며 임의 쓰기 성능에 대한 대략적인 지침으로 사용될 수 있습니다.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Seagate는 5980RPM이므로 Toshiba가 20 % 더 빠를 것으로 예상 할 수 있습니다. 이 벤치 마크는 약 3 배 (200 %) 빠르다는 것을 보여 주므로이 벤치 마크는 성능 저하로 이어지고 있습니다. Shingled (SMR) 디스크는 여전히 unshingled (PMR) 디스크의 성능 ext4와 일치하지 않습니다. 최고의 성능은 8TB 파티션이있는 nilfs2 (클리너를 실행할 필요가 없음) 였지만, ext4가있는 Toshiba보다 훨씬 느 렸습니다.

위의 벤치 마크를보다 명확하게하기 위해 각 디스크의 ext4 성능과 관련하여 벤치 마크를 표준화하는 것이 도움이 될 수 있습니다.

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

우리는 SMR 디스크에서 btrfs가 ext4에있는 전체 ops에서 가장 큰 이점을 가지지 만 랜덤 추가에 대한 패널티는 비율만큼 극적이지 않다는 것을 알 수 있습니다. 이로 인해 SMR 디스크에서 btrfs로 이동할 수 있습니다. 반면, 지연 시간이 짧은 임의 추가가 필요한 경우이 벤치 마크에서는 특히 SMR에서 xfs를 원합니다. SMR / PMR이 파일 시스템 선택에 영향을 줄 수 있지만 최적화하는 작업 부하가 더 중요하다고 생각합니다.

또한 다락방 기반 벤치 마크를 실행했습니다. 다락방 실행 기간 (8TB SMR 전체 디스크 파티션에서)은 다음과 같습니다.

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

각 경우에 다락방 리포지토리에는 다음과 같은 통계가있었습니다.

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

다락방에 동일한 1TB 디스크의 두 번째 사본을 추가하는 데이 세 파일 시스템 각각에서 4.5 시간이 걸렸습니다. 벤치 마크 및 smartctl정보 의 원시 덤프는 다음 에 있습니다. http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

당신이 경우 rsync 에서 SMR 드라이브, 파일 시스템이 장착되어 있는지 확인 read-only또는과 noatime옵션을 선택합니다.

그렇지 않으면 SMR 드라이브는 각 파일 rsync 읽기에 대한 타임 스탬프를 작성해야하므로 성능이 크게 저하 (여기서는 약 80mb / s에서 3-5mb / s까지)되고 헤드 마모 / 클릭 노이즈가 발생합니다.

이미 성능이 좋지 않은 rsync 작업이 실행중인 경우 중지 할 필요가 없으면 소스 파일 시스템을 다시 마운트 할 수 있습니다.

sudo mount -o remount,ro  /path/to/source/fs

드라이브가 버퍼에있는 모든 데이터의 쓰기를 완료 할 때까지 그 효과는 즉시 나타나지 않으며 인내심을 갖고 10-20 분 동안 기다리십시오. 이 조언은 시도되고 정상적으로 테스트되었습니다.

경우에도 적용 할 수 rsync보내고 에 파일 시스템이 파일을 완전히 디스크에 기록 된 후에 타임 스탬프를 업데이트하려고하는 경우 즉, SMR 드라이브. 이로 인해 순차적 워크로드가 발생하고 막대한 양의 데이터가 지속적으로 다시 작성되어 마모를 유발합니다. 다음 이 도움 이 될 수 있습니다.

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

rsync가 실행되기 전에이 작업을 수행해야합니다. 파일 시스템이 주로 SSD에 최적화 된 경우 다른 요인으로 인해이 옵션이 중요하지 않을 수 있습니다 (예 : 버퍼되지 않은 FAT / MFT 업데이트, 병렬화 된 쓰기 등).

dd bs=32M어쨌든 전체 파일 시스템을 백업하려는 경우 SMR 대상에서 파일 시스템 을 사용한 다음 크기를 조정하십시오 (이 경우 각 파일을 모두 전송하기 위해 마운트하고 rsync를 실행할 필요가 없음).

실제 사용중인 하드웨어는 Seagate 드라이브 관리 SMR 8tb 소비자 드라이브였습니다. 마일리지는 다른 하드웨어에 따라 다를 수 있습니다.