Hệ thống tập tin Linux nhanh nhất trên đĩa Shingled

Có sự quan tâm đáng kể trong các ổ đĩa zona. Những thứ này đặt các rãnh dữ liệu gần nhau đến mức bạn không thể ghi vào một rãnh mà không bị ghi đè tiếp theo. Điều này có thể tăng công suất thêm 20% hoặc hơn, nhưng dẫn đến các vấn đề khuếch đại ghi. Có công việc đang được tiến hành trên các hệ thống tập tin được tối ưu hóa cho các ổ Shingled, ví dụ: xem: https://lwn.net/Articles/591782/

Một số đĩa được lưu trữ như kho lưu trữ Seagate 8TB có vùng bộ đệm để ghi ngẫu nhiên, cho phép thực hiện tốt trên các hệ thống tệp chung. Đĩa thậm chí có thể khá nhanh trên một số khối lượng công việc phổ biến, lên tới 200MB / giây ghi. Tuy nhiên, điều được dự kiến ​​là nếu bộ đệm ghi ngẫu nhiên ghi tràn, hiệu năng có thể bị ảnh hưởng. Có lẽ, một số hệ thống tập tin tốt hơn trong việc tránh ghi ngẫu nhiên nói chung hoặc các mẫu ghi ngẫu nhiên có khả năng tràn bộ đệm ghi được tìm thấy trong các ổ đĩa đó.

Là một hệ thống tập tin chính trong nhân linux tốt hơn trong việc tránh hình phạt hiệu năng của các đĩa bị vỡ hơn so với ext4?

Các hệ thống tập tin có cấu trúc Copy-on-Write và Log có thể mang lại hiệu năng tốt hơn trên các đĩa bị vỡ bằng cách giảm việc ghi ngẫu nhiên. Các điểm chuẩn phần nào hỗ trợ điều này, tuy nhiên, những khác biệt về hiệu suất này không dành riêng cho các đĩa shingled. Chúng cũng xảy ra trên một đĩa không có vỏ bọc được sử dụng như một điều khiển. Do đó, việc chuyển sang đĩa shingled có thể không liên quan nhiều đến sự lựa chọn hệ thống tập tin của bạn.

Hệ thống tập tin nilfs2 cho hiệu năng khá tốt trên đĩa SMR. Tuy nhiên, điều này là do tôi đã phân bổ toàn bộ phân vùng 8TB và điểm chuẩn chỉ ghi ~ 0,5TB để trình dọn dẹp nilfs không phải chạy. Khi tôi giới hạn phân vùng ở mức 200 GB, điểm chuẩn của nilfs thậm chí không hoàn thành thành công. Nilfs2 có thể là một lựa chọn hiệu suất tốt nếu bạn thực sự sử dụng đĩa "lưu trữ" làm đĩa lưu trữ, nơi bạn giữ tất cả dữ liệu và ảnh chụp nhanh được ghi vào đĩa, vì khi đó trình dọn dẹp nilfs không phải chạy.

Tôi hiểu rằng ST8000AS0002-1NA17Zổ đĩa seagate 8TB mà tôi đã sử dụng cho bài kiểm tra có vùng bộ nhớ cache ~ 20GB . Tôi đã thay đổi cài đặt máy chủ tệp filebench mặc định để bộ điểm chuẩn được đặt sẽ là ~ 125GB, lớn hơn khu vực bộ đệm không được lưu trữ:

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

Bây giờ cho dữ liệu thực tế. Số lượng ops đo hiệu năng của máy chủ "tổng thể" trong khi ms / op đo độ trễ của phần bổ sung ngẫu nhiên và có thể được sử dụng như một hướng dẫn sơ bộ về hiệu suất ghi ngẫu nhiên.

$ 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]

Vì Seagate là 5980RPM, người ta có thể ngây thơ mong đợi Toshiba sẽ nhanh hơn 20%. Các điểm chuẩn này cho thấy nó nhanh hơn khoảng 3 lần (200%), vì vậy những điểm chuẩn này đang chạm vào hình phạt hiệu suất shingled. Chúng tôi thấy đĩa Shingled (SMR) vẫn không thể phù hợp với hiệu suất ext4 với trên đĩa không có vỏ bọc (PMR). Hiệu suất tốt nhất là với nilfs2 với phân vùng 8TB (vì vậy trình dọn dẹp không cần phải chạy), nhưng ngay cả khi đó nó chậm hơn đáng kể so với Toshiba với ext4.

Để làm cho các điểm chuẩn ở trên rõ ràng hơn, có thể giúp bình thường hóa chúng so với hiệu suất của ext4 trên mỗi đĩa:

                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

Chúng tôi thấy rằng trên btrfs đĩa SMR có hầu hết lợi thế trên các ops tổng thể mà nó có trên ext4, nhưng hình phạt đối với các phụ lục ngẫu nhiên không ấn tượng như tỷ lệ. Điều này có thể dẫn một người chuyển sang btrfs trên đĩa SMR. Mặt khác, nếu bạn cần các phụ lục ngẫu nhiên có độ trễ thấp, điểm chuẩn này cho thấy bạn muốn xfs, đặc biệt là trên SMR. Chúng tôi thấy rằng mặc dù SMR / PMR có thể ảnh hưởng đến sự lựa chọn hệ thống tập tin của bạn, việc xem xét khối lượng công việc mà bạn đang tối ưu hóa có vẻ quan trọng hơn.

Tôi cũng đã chạy một tiêu chuẩn dựa trên gác mái. Thời lượng của gác mái chạy (trên phân vùng đĩa đầy đủ 8TB SMR) là:

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

Trong mỗi trường hợp, kho gác mái có các số liệu thống kê sau:

                       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

Thêm một bản sao thứ hai của cùng một đĩa 1 TB vào gác mái mất 4,5 giờ trên mỗi ba hệ thống tệp này. Một kết xuất thô của các điểm chuẩn và smartctlthông tin có tại: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmark/SMR

Nếu bạn rsync từ một ổ đĩa SMR, hãy đảm bảo rằng hệ thống tập tin được gắn kết read-onlyhoặc với noatimetùy chọn.

Nếu không, ổ SMR sẽ cần ghi dấu thời gian cho mỗi lần đọc rsync tệp, dẫn đến suy giảm hiệu suất đáng kể (từ khoảng 80 mb / s xuống còn 3-5 mb / s ở đây) và tiếng ồn khi đeo / nhấp vào đầu.

Nếu bạn đã có một công việc rsync đang chạy với hiệu suất kém, không cần phải dừng nó, bạn có thể kết nối lại hệ thống tệp nguồn đang làm

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

Hiệu quả sẽ không được nhìn thấy ngay lập tức, hãy kiên nhẫn và đợi 10 đến 20 phút, cho đến khi ổ đĩa kết thúc để ghi ra tất cả dữ liệu vẫn còn trong bộ đệm của nó. Lời khuyên này đã được thử và kiểm tra ok.

Điều này cũng có thể áp dụng khi rsyncing vào ổ SMR, tức là nếu hệ thống tệp cố cập nhật dấu thời gian sau khi tệp đã được ghi hoàn toàn vào đĩa. Khối lượng công việc tuần tự này và các dải dữ liệu khổng lồ liên tục được viết lại, góp phần làm hao mòn ổ đĩa. Sau đây có thể giúp:

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

Điều này phải được thực hiện, trước khi rsync được chạy; các yếu tố khác có thể khiến tùy chọn này không đáng kể, tức là cập nhật FAT / MFT không có bộ đệm, ghi song song nếu hệ thống tệp được tối ưu hóa chủ yếu cho SSD, v.v.

Hãy thử sử dụng dd bs=32Mvà sau đó thay đổi kích thước hệ thống tệp trên mục tiêu SMR, nếu bạn muốn sao lưu toàn bộ hệ thống tệp (không cần phải gắn và chạy rsync để vận chuyển từng tệp trong trường hợp này).

Phần cứng thực tế đang sử dụng là ổ đĩa Seagate được quản lý ổ đĩa tiêu dùng SMR 8tb. Số dặm của bạn có thể thay đổi với phần cứng khác.