Sử dụng ổ đĩa 4k với md / LVM / dm-crypt


8

Tôi biết rằng tôi phải căn chỉnh các ổ đĩa 4k của mình theo bội số của 8 cung, nhưng còn md-RAID / LVM / dm-crypt thì sao? Làm thế nào để tôi nói với các lớp này rằng ổ đĩa của tôi là 4k? Nếu họ không tôn trọng kích thước khu vực 4k, việc căn chỉnh phân vùng là vô ích. Làm cách nào để tôi căn chỉnh các lớp LVM / md / crypto? Cảm ơn.


2
Tôi chỉ nghĩ, "Hmm, 4 kilobyte dường như quá nhỏ cho một ổ đĩa". Có lẽ đó là 640k mới.
Tom O'Connor

@Tom. Nhiều hệ thống tập tin sử dụng kích thước khối 4 KB, vì vậy các lĩnh vực lớn hơn sẽ dẫn đến rất nhiều hiệu suất đọc-sửa đổi-ghi-hiệu suất. Thứ hai, động lực hướng tới các lĩnh vực lớn hơn chủ yếu là để tăng hiệu quả ECC và có lợi nhuận giảm dần để làm cho nó thậm chí còn lớn hơn.
janneb

@janneb Bạn là Buzz Killington AICMFP
Tom O'Connor

Câu trả lời:


4

Hãy cẩn thận! nhãn gpt, được yêu cầu cho các đĩa> 2 TiB, dài 39 (512 byte). Vì vậy, nếu bạn tạo phân vùng đầu tiên của mình ngay sau nhãn, nó sẽ không nằm trên ranh giới 4KiB.

GNU parted không làm điều này theo mặc định, có thể vì nhiều ổ đĩa "Định dạng nâng cao" tuyên bố sai rằng các lĩnh vực vật lý của họ , không chỉ các lĩnh vực logic của họ, vẫn chỉ là 512B.

Vì vậy, nếu bạn đang sử dụng GNU chia tay, hãy đảm bảo rằng mỗi phân vùng bắt đầu trên LBA chia hết cho 8 (LBA vẫn là 512B, vì vậy 8 * 512B = 4KiB). Các LBA có nguồn gốc từ 0, vì vậy hãy bắt đầu phân vùng đầu tiên ở "40s".

Ngoài ra, nếu bạn sử dụng GRUB, hãy chừa chỗ cho bootstrap giai đoạn hai của nó. Nhãn MS-DOS là 63 lĩnh vực, có đủ chỗ chưa sử dụng để GRUB cất giấu bootstrap giai đoạn hai của nó, nhưng không có không gian chưa sử dụng trong nhãn gpt. Vì vậy, hãy tạo một phân vùng nhỏ 1, đặt cờ "bios_grub" và sau đó tạo các phân vùng "thực" của bạn sau đó - đảm bảo rằng mỗi và mọi thứ bắt đầu trên một LBA là bội số của 8.


3

Xem https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

Phiên bản ngắn là nếu bạn có một bản phân phối gần đây, nó sẽ tự động làm đúng. Đối với các distro cũ, nó phức tạp hơn một chút.

Đối với LVM, bạn nên điều tra --dataalignmenttùy chọn pvcreatehoặc thậm chí cho các bản phát hành cũ hơn -–metadatasize.

MD, AFAIK, đặt siêu dữ liệu của chính nó vào cuối các phân vùng, vì vậy nó phải luôn được căn chỉnh theo phân vùng bên dưới.

Đối với mkfs, một lần nữa hệ thống tập tin nên được liên kết với phân vùng bên dưới. Đối với một số hệ thống tệp, bạn có thể thêm tùy chọn cho chiều rộng sọc và kích thước sọc trong trường hợp bạn đang chạy trên thiết bị RAID, để hệ thống tệp có thể cố gắng căn chỉnh các thứ trên ranh giới sọc RAID.


1

vấn đề chủ yếu là sự liên kết của phân vùng bắt đầu với cấu trúc của đĩa bên dưới. để giữ các đĩa tương thích ngược 'nói dối' với bios / os rằng chúng có các cung 512B, trong khi thực tế chúng có các phân vùng 4096B trong trường hợp ổ cứng hiện đại, các cung 32-64kB trong trường hợp hầu hết các cuộc đột kích / ssds phổ biến.

phân vùng không đúng sẽ làm tổn thương hiệu suất của bạn. tôi đã thực hiện một số điểm chuẩn chỉ trên các phân vùng thông thường trên đỉnh đĩa - không có lvm và kết quả của tôi được đo bằng bonnie ++ là không có sự liên kết chính xác:

Sequential Output Block: 29MB/s
Sequential Output Rewrite: 20MB/s

với sự liên kết:

Sequential Output Block: 70MB/s
Sequential Output Rewrite: 37MB/s

kiểm tra điều này để căn chỉnh lvm.


0

Hầu hết các bản phân phối mới hơn được cập nhật để biết về điều 4K. Tôi mới xây dựng một thiết lập md-RAID / LVM / XFS trên một loạt các ổ đĩa 2TB mà không gặp vấn đề gì. Không làm gì đặc biệt.


tôi không đồng ý ... chắc chắn - mọi thứ đều hoạt động, nhưng các phân vùng bị căn chỉnh sai làm tổn hại đến hiệu suất.
pQd

Vâng, điều này đặt ra câu hỏi. Tôi có một số cuộc tấn công khác nhau bằng cách sử dụng các ổ đĩa từ 2TB đến 500GB với LVM trên đầu chúng được định dạng bằng XFS. Vậy chính xác mọi thứ sẽ hoạt động như thế nào nếu tất cả các ổ đĩa không phải là 4k? Tôi rất thích làm điểm chuẩn nhưng máy chủ terra của tôi chậm hơn các ổ đĩa, vì vậy nó sẽ là vô nghĩa.
Hiên nhà
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.