mdadm và 4k sector (định dạng nâng cao)

Có rất nhiều câu hỏi trên Serverfault về việc sắp xếp các đĩa 4k sector, nhưng có một điều chưa thực sự rõ ràng đối với tôi.

Tôi đã căn chỉnh thành công RAID1 + LVM của mình. Một trong những điều tôi đã làm là sử dụng mdadm superblock phiên bản 1.0 (lưu trữ siêu khối ở cuối đĩa).

Trang này nói điều này:

Các phiên bản phụ khác nhau lưu trữ siêu khối tại các vị trí khác nhau trên thiết bị, ở cuối (cho 1.0), khi bắt đầu (cho 1.1) hoặc 4K từ đầu (cho 1.2). "1" tương đương với "1.0". "Mặc định" tương đương với "1.2".

Là phiên bản 1.2, mặc định, được tạo cho các ổ đĩa 4k sector? Theo cách tôi nhìn thấy thì không phải như vậy, vì 4k từ lúc bắt đầu + chiều dài của siêu khối không phải là vô số 4k (siêu khối dài khoảng 200 byte, nếu tôi nhớ chính xác).

Bất kỳ cái nhìn sâu sắc về điều này đều được chào đón.

biên tập:

dưới đây đã được trả lời rằng siêu khối mdadm 1.1 và 1.2 có nghĩa là căn chỉnh 4k. Tôi vừa tạo một cuộc đột kích toàn thiết bị với:

mdadm --create /dev/md4 -l 1 -n 2 /dev/sdb /dev/sdd

Sau đó, tôi đã thêm một khối lượng logic cho nó:

vgcreate universe2 /dev/md4

Mảng được đồng bộ hóa ở 16 MB / s:

md4 : active raid1 sdd[1] sdb[0]
      1465137424 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.8% (13100352/1465137424) finish=1471.6min speed=16443K/sec

Vì vậy, tôi nghi ngờ nó được liên kết chính xác.

(các ổ đĩa là 1,5 TB WD EARS. Tôi có chúng trong máy tính để bàn của mình và chúng được đồng bộ hóa với tốc độ khoảng 80 MB / s.)

Chỉnh sửa2:

Đây là --examine đầu ra:

# mdadm --examine /dev/sdb
/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 79843828:7d939cce:1c8f0b32:cf339870
           Name : brick:4  (local to host brick)
  Creation Time : Sat Jul  9 10:47:33 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 2930275120 (1397.26 GiB 1500.30 GB)
     Array Size : 2930274848 (1397.26 GiB 1500.30 GB)
  Used Dev Size : 2930274848 (1397.26 GiB 1500.30 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : dd2e3b5f:33214b96:1cb88169:25deb050

    Update Time : Sat Jul  9 10:49:06 2011
       Checksum : 4f7cd785 - correct
         Events : 1


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)

Dữ liệu bù là 2048 lĩnh vực, được chia cho 8, vì vậy người ta sẽ nghĩ rằng nó ổn. Nhóm âm lượng có kích thước phạm vi vật lý là 4 MiB, cũng có thể chia cho 8. Nhưng điều đó thậm chí không quan trọng, vì đồng bộ hóa lại không liên quan đến những gì thiết bị chứa.

Một chỉnh sửa khác: nó dường như không phải là một vấn đề liên kết; vì hdparm -t hiển thị tốc độ đọc rất thấp cho một trong các đĩa (30 MB / s). Một cái gì đó khác là không ổn.

Edit2: Tôi không bao giờ nhớ cập nhật bài viết này khi tôi tìm thấy câu trả lời. Tất cả được liên kết độc đáo. Một trong những đĩa bị hỏng. Rõ ràng đó là trên chân cuối cùng của nó và thậm chí đã phá vỡ tại một số điểm. Một đĩa thay thế hoạt động tốt.

Có, nó được thực hiện cho liên kết ngành 4k.

Với các siêu khóa 1.1 và 1.2, không gian được dành riêng ở đầu mỗi đĩa để siêu khối không bị chà đạp. Mã tạo siêu khối buộc không gian dành riêng này là bội số của 4kB. Tất cả các lần đọc vật lý được bù từ phần cuối của không gian dành riêng này , không phải từ phần cuối của siêu khối. Do đó, điều này duy trì sự liên kết cho bất kỳ kích thước khu vực nào chia đều cho 4kB.

Nếu bạn quan tâm, đây là bằng chứng từ mã nguồn mdadm ( super1.c):

/* force 4K alignment */
reserved &= ~7ULL;
sb->data_offset = __cpu_to_le64(reserved);

Và data_offsettham số này được sử dụng bởi mã RAID1 trong kernel để bù cho các lần đọc vật lý, ví dụ như trong đường dẫn đọc:

read_bio->bi_sector = r1_bio->sector + mirror->rdev->data_offset