Hệ thống tệp Linux hiệu suất cao nhất để lưu trữ nhiều tệp nhỏ (HDD, không phải SSD) là gì?


43

Tôi có một cây thư mục chứa nhiều tệp nhỏ và một số lượng nhỏ tệp lớn hơn. Kích thước trung bình của một tập tin là khoảng 1 kilobyte. Có 210158 tệp và thư mục trong cây (số này có được bằng cách chạy find | wc -l).

Một tỷ lệ nhỏ các tệp được thêm / xóa / ghi lại nhiều lần mỗi tuần. Điều này áp dụng cho các tệp nhỏ, cũng như (số lượng nhỏ) tệp lớn hơn.

Các hệ thống tệp mà tôi đã thử (ext4, btrfs) có một số vấn đề với việc định vị tệp trên đĩa. Trong một khoảng thời gian dài hơn, các vị trí vật lý của các tệp trên đĩa (phương tiện quay, không phải đĩa trạng thái rắn) sẽ được phân phối ngẫu nhiên hơn. Hậu quả tiêu cực của phân phối ngẫu nhiên này là hệ thống tệp ngày càng chậm (chẳng hạn như: chậm hơn 4 lần so với hệ thống tệp mới).

Có một hệ thống tập tin Linux (hoặc một phương pháp bảo trì hệ thống tập tin) không bị suy giảm hiệu suất này và có thể duy trì cấu hình hiệu suất ổn định trên phương tiện quay không? Hệ thống tập tin có thể chạy trên Fuse, nhưng nó cần phải đáng tin cậy.


Nếu bạn biết tệp nào sẽ lớn / không thay đổi thường xuyên và tệp nào sẽ nhỏ / thường xuyên thay đổi, bạn có thể muốn tạo hai hệ thống tệp với các tùy chọn khác nhau, phù hợp hơn với từng kịch bản. Nếu bạn cần chúng có thể truy cập được vì chúng là một phần của cùng một cấu trúc, bạn có thể thực hiện một số thủ thuật với mount, symlink.
Marcin

Tôi lặng lẽ ngạc nhiên khi biết rằng btrfs (với tính năng sao chép trên văn bản) đã chậm chạp với bạn trong một khoảng thời gian. Tôi tò mò muốn có kết quả được chia sẻ từ bạn, có thể giúp nhau theo hướng điều chỉnh hiệu suất mới với nó.
Nikhil Mulley

có một zfs trực tuyến động vật mới trên Linux, có sẵn trong chế độ gốc và triển khai cầu chì, trong trường hợp bạn muốn có một cái nhìn.
Nikhil Mulley

Tôi đã thử zfs trên linux một lần, khá không ổn định. Quản lý để khóa hoàn toàn hệ thống tập tin khá thường xuyên. Box sẽ hoạt động, nhưng mọi quyền truy cập vào FS sẽ bị treo.
Patrick

Bài đăng tương tự serverfault.com/questions/6711/
Mạnh

Câu trả lời:


47

Hiệu suất

Tôi đã viết một Điểm chuẩn nhỏ ( nguồn ), để tìm hiểu, hệ thống tệp nào hoạt động tốt nhất với hàng trăm nghìn tệp nhỏ:

  • tạo 300000 tệp (512B đến 1536B) với dữ liệu từ / dev / urandom
  • viết lại 30000 tệp ngẫu nhiên và thay đổi kích thước
  • đọc 30000 tập tin liên tiếp
  • đọc 30000 tệp ngẫu nhiên
  • xóa tất cả các tệp tin

  • đồng bộ hóa và xóa bộ nhớ cache sau mỗi bước

Kết quả (thời gian trung bình tính bằng giây, thấp hơn = tốt hơn):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Kết quả:
Mặc dù Ext4 có hiệu suất tổng thể tốt, ReiserFS cực kỳ nhanh trong việc đọc các tệp tuần tự. Hóa ra XFS chậm với nhiều tệp nhỏ - bạn không nên sử dụng nó cho trường hợp sử dụng này.

Vấn đề phân mảnh

Cách duy nhất để ngăn hệ thống tệp phân phối tệp qua ổ đĩa, là giữ cho phân vùng chỉ lớn như bạn thực sự cần, nhưng chú ý không làm cho phân vùng quá nhỏ, để ngăn chặn phân mảnh. Sử dụng LVM có thể rất hữu ích.

đọc thêm

Arch Wiki có một số bài viết tuyệt vời liên quan đến hiệu suất hệ thống tệp:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices


4
Bạn nên chỉ định phiên bản kernel nào mà bạn dựa trên sự so sánh đó. XFS có một số yếu tố quan trọng về tốc độ ở một trong những hạt nhân gần đây (nghĩ rằng đó là 2.6.31, nhưng không trích dẫn tôi về điều đó).
Patrick

1
btrfs nội bộ thực hiện thủ thuật lvm của bạn. Nó phân bổ các phần nhỏ hơn của đĩa và đặt các tệp vào các phần đó, sau đó chỉ phân bổ một phần khác của đĩa khi các phần hiện có lấp đầy.
psusi

1
Điều đó đúng với bất kỳ hệ thống tập tin nào. Đó là lý do tại sao các ứng dụng sử dụng những thứ như fsync ().
psusi

2
@taffer, nó là. Các giao dịch có tác dụng tương tự như tạp chí trong các hệ thống tập tin khác: chúng bảo vệ siêu dữ liệu fs. Về lý thuyết, chúng có thể được sử dụng bởi các ứng dụng theo cách bạn mô tả, nhưng hiện tại không có api để cho phép các ứng dụng mở và đóng giao dịch.
psusi

1
@taffer "Điểm chuẩn gần đây" của bạn là từ tháng 4 năm 2015, trên ba tuổi và chỉ sử dụng XFS với các tùy chọn mặc định. Điều này trước ngày xfspross 3.2.3 làm cho XFS v5 trở thành mặc định và tất cả những lợi ích mà nó mang lại. Nó cũng không được định dạng với -m finazed = 1, một công cụ thay đổi trò chơi cho hiệu suất XFS với các tệp nhỏ và cập nhật siêu dữ liệu nặng. Không, không có đạn bạc, nhưng dựa trên ý kiến ​​của bạn về các điểm chuẩn cũ là không khôn ngoan, đặc biệt là khi các tính năng thay đổi hiệu suất chính bị bỏ qua, không khả dụng hoặc bị vô hiệu hóa.
Jody Lee Bruchon

7

Tôi đang sử dụng ReiserFS cho nhiệm vụ này, nó được tạo ra đặc biệt để xử lý rất nhiều tệp nhỏ. Có một văn bản dễ đọc về nó tại wiki funtoo.

ReiserFS cũng có một loạt các tính năng nhằm cải thiện hiệu suất tệp nhỏ. Không giống như ext2, ReiserFS không phân bổ không gian lưu trữ trong các khối cố định một hoặc bốn k. Thay vào đó, nó có thể phân bổ kích thước chính xác mà nó cần.


1
Có những vấn đề về tính ổn định cũng như với ReiserFS - vì vậy, RH và SuSE đã bỏ FS đó. Từ BTRFS nguyên tắc (dựa trên BTree) nên tương đương.
Nils


0

XFS được ghi nhận để thực hiện rất tốt trong các tình huống như thế này. Đây là một phần lý do tại sao chúng tôi sử dụng nó trong công việc của tôi cho các cửa hàng thư của chúng tôi (có thể chứa hàng trăm ngàn tệp trong 1 thư mục). Nó có khả năng chịu lỗi tốt hơn ReiserFS, được sử dụng rộng rãi hơn nhiều và nói chung là một hệ thống tệp rất trưởng thành.

Ngoài ra, XFS hỗ trợ chống phân mảnh trực tuyến. Mặc dù nó sử dụng một kỹ thuật phân bổ bị trì hoãn dẫn đến việc phân mảnh ít hơn (so với các hệ thống tập tin khác) để bắt đầu.


20
XFS được ghi nhận vì hoạt động rất tốt trong các tình huống như thế này. [cần dẫn nguồn]
taffer

8
Ehm, xfs đặc biệt được biết đến với điều ngược lại: làm việc thực sự tốt với các tệp lớn, nhưng không tốt trên các tệp nhỏ! Nhìn vào điểm chuẩn đầy đủ này chẳng hạn (hoặc chuyển ngay đến kết luận ở trang 10 ^^): ilsistemista.net/index.php/linux-a-unix/ phỏng
Levite

1
@Levit Tôi nghĩ bạn đang đọc sai báo cáo đó. Báo cáo cho thấy rất rõ rằng XFS thực hiện rất tốt đối với IO ngẫu nhiên. Nhưng bên cạnh đó, báo cáo không đề cập đến loại kịch bản trong câu hỏi này, rất nhiều tệp. IO ngẫu nhiên là một điều, số lượng lớn các tệp là nơi ext * rơi trên mặt của nó.
Patrick

2
Nơi duy nhất XFS thực sự tốt hơn là có các thao tác đọc / ghi ngẫu nhiên (vẫn có vẻ lạ khi một mẫu đọc thực sự ngẫu nhiên trên đĩa cơ có thể nhận được 10MB / s - dường như tôi giống như một số tối ưu hóa không bay trong thế giới thực (imho)), trong khi ở trang 7, nó chỉ hiển thị những gì tôi đã nói trước đó, XFS thực sự tốt trong việc xử lý các tệp lớn! Nhìn vào trang 3 & 5, đặc biệt trên 3 bạn thấy nó xử lý các tệp nhỏ rõ ràng không tốt như ext! Tôi thực sự không có bất cứ điều gì chống lại XFS, nhưng từ những gì bạn tìm thấy ở mọi nơi, đó không phải là lựa chọn tối ưu cho nhiều tệp nhỏ, đó là tất cả những gì tôi đang nói!
Levite

5
XFS cũng có thể cực kỳ chậm khi nói đến các tệp lớn, nếu các tệp này được mở rộng ngẫu nhiên / chậm với các đoạn nhỏ trong một thời gian dài. (Mẫu điển syslogdhình.) Ví dụ: bên cạnh tôi trong thiết lập XFS qua MD tôi vừa quan sát thấy, việc xóa tệp 1,5 GB mất 4,75 phút (!) Trong khi ổ đĩa bị giới hạn ở mức 100 giao dịch / giây ở tốc độ ghi hơn 2 MB / s. Điều này cũng ảnh hưởng đến hiệu suất của các hoạt động IO song song khác trên cùng một ổ đĩa, vì ổ đĩa đã được tối đa hóa. Không bao giờ thấy bất cứ điều gì như thế trong các FS khác (hoặc đang được kiểm tra điểm chuẩn).
Tino
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.