Làm cách nào để kiểm tra xem tất cả ghi vào ổ cứng của tôi có được liên kết với các lĩnh vực 4k của nó không?


9

Tôi đang sử dụng Linux với 4 ổ cứng sử dụng 4k sector. Có một số lớp giữa hệ thống tệp của tôi và các thiết bị thô: Đĩa> Linux Raid 5> dm-crypt> LVM.

Mỗi tài nguyên tôi đã tìm thấy đã giải thích cách thiết lập từng lớp để đảm bảo rằng ghi trên đầu lớp đó sẽ được căn chỉnh theo ranh giới của khu vực 4k. Tuy nhiên, tôi không tìm thấy bất cứ điều gì giải thích làm thế nào để xác minh rằng việc ghi vào ổ cứng thực sự đang xảy ra ở ranh giới 4k.

Tôi không quan tâm đến việc kiểm tra lại thiết lập của mình để sử dụng logic để xác định xem nó có được căn chỉnh chính xác không. Tôi muốn kiểm tra những gì đang thực sự xảy ra khi ghi được thực hiện vào đĩa.

Làm cách nào tôi có thể đăng nhập hoặc xem địa chỉ và kích thước của ghi được thực hiện trên ổ đĩa cứng của mình, để tôi có thể xác minh rằng chúng được căn chỉnh chính xác?

Câu trả lời:


2

Đã tự hỏi mình câu hỏi tương tự một thời gian trước đây và chỉ đơn giản là làm như sau:

Đã ghi với shell một vài lần một chuỗi khá bất thường đối với một tệp (một cái gì đó như "WackaWacka") Sau đó chỉ cần tìm kiếm với một kết xuất hex (sử dụng od ) nội dung thực tế của đĩa và kiểm tra xem lần xuất hiện đầu tiên của chuỗi chính xác vào đầu một khối 4k.

Gợi ý: Không sử dụng trình chỉnh sửa - nó có thể tạo các tệp tạm thời mà bạn không biết có thể chứa chuỗi. Làm như thế này:

 $ for i in 1 2 3 4 5 ...
 >  do
 >   echo "WackaWacka!"
 >  done > mytestfile

Vì vậy, .sh_history có thể chứa chuỗi tìm kiếm, nhưng không phải 5 lần liên tiếp ;-)

Và sau đó, chỉ cần tìm kiếm:

 # sync
 # od -c /dev/sda | grep 'W   a   c   k   a'

Chà, tốt nhất là thực hiện trên một đĩa khá trống để tránh truyền dữ liệu qua Gigabyte dữ liệu ;-)


1
Vì dm-crypt là một trong các lớp trong ngăn xếp của tôi, giải pháp này là không đủ, vì các ký tự này sẽ không được ghi vào đĩa.
Brian Pellin

Điều đó thật xấu. Chỉ có giải pháp khác tôi có thể nghĩ là thay đổi rõ ràng một khối 4k trong tệp và kiểm tra xem chỉ nội dung của một khối vật lý trên đĩa có thay đổi không (hoặc nếu hai khối liên tiếp bị ảnh hưởng) - và điều này sẽ chỉ hoạt động nếu dữ liệu không được nén bởi lớp mã hóa. Tuy nhiên, người ta phải biết, trên đó khối tệp được lưu trữ và việc tìm kiếm bất kỳ thay đổi nào có thể khó khăn trên các đĩa lớn.
ktf

2

Viết một khối 4k và xem lượng dữ liệu được đọc / ghi với iostat(Các cột 'Blk_read' 'Blk_wrtn'). Nếu dữ liệu không được căn chỉnh, một lần ghi sẽ kích hoạt đọc trước và sẽ kích hoạt hơn 4k ghi.

Bạn sẽ cần cẩn thận để không đo bất kỳ cập nhật siêu dữ liệu nào, mặc dù ... hoặc chỉ nhấn chìm chúng bằng cách thực hiện 1000 lần ghi 4k .... Vì vậy, hãy đảm bảo không có gì khác là quét đĩa hoặc giữ các tệp đang mở (tôi nghĩ lsofsẽ là đủ chưa?), sau đó mở một tệp mới, đợi, chạy iostat, ghi 4k vào tệp, đồng bộ hóa ghi (hoặc chỉ đợi một lúc?) sau đó kiểm tra iostatlại.

Điều này dường như cung cấp một đầu ra hợp lý cho tôi:

iostat  -d /dev/hdb3
dd if=/dev/urandom of=/mount/path/ofhdb3/tmptest bs=4k count=10000 conv=fdatasync
iostat  -d /dev/hdb3

iostatTrang man của Note tuyên bố báo cáo theo các khối 512 byte và tôi thấy chỉ có hơn 80000 khối bổ sung được viết và không có khối nào được đọc. Nếu căn chỉnh của bạn bị tắt, bạn sẽ thấy số lần đọc tương tự (vì để viết 4k căn chỉnh sai, yêu cầu đọc hai khối bị ảnh hưởng, làm biến đổi chúng và viết lại). Trong thực tế, lý do duy nhất căn chỉnh là quan trọng là để tránh các lần đọc như vậy (vì vậy đó thực sự là điều bạn muốn tìm kiếm: liệu trình kích hoạt khối lượng công việc ghi có đọc không?)


Bạn có biết nếu iuler đang báo cáo về số lần đọc / ghi mà HĐH thực hiện cho thiết bị chặn hay con số này dựa trên ổ đĩa báo cáo có bao nhiêu khối đã đọc và ghi?
Brian Pellin

Tôi nghi ngờ nó từ sự trừu tượng hóa thiết bị khối hệ điều hành, không phải trực tiếp từ ổ đĩa, nhưng tôi không biết chắc chắn. Tôi cũng không chắc nó sẽ là "bên trên" hay "bên dưới" lớp dm-crypt.
PT
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.