Làm cách nào để mô phỏng đĩa bị lỗi trong khi thử nghiệm?

Question

Trong máy ảo Linux (máy trạm Vmware hoặc tương tự), làm thế nào tôi có thể mô phỏng lỗi trên đĩa làm việc trước đây?

Tôi có một tình huống xảy ra trong quá trình sản xuất khi đĩa bị lỗi (có thể là bộ điều khiển, cáp hoặc sự cố phần sụn). Rõ ràng điều này là không thể dự đoán hoặc tái sản xuất, tôi muốn kiểm tra giám sát của tôi để đảm bảo rằng nó cảnh báo chính xác.

Tôi lý tưởng muốn có thể mô phỏng tình huống không ghi được nhưng đọc thành công, cũng như lỗi hoàn toàn, tức là giao diện scsi báo cáo lỗi về hạt nhân.

Answer 1

Có một số lớp mà tại đó lỗi đĩa có thể được mô phỏng. Nếu bạn đang thử nghiệm một chương trình không gian người dùng đơn lẻ, có lẽ cách tiếp cận đơn giản nhất là để xen kẽ các cuộc gọi thích hợp (ví dụ: write()) và đôi khi họ có trả lại lỗi. Thư viện tiêm lỗi libfiucan do this sử dụng công cụ fiu-run của nó.

Một cách tiếp cận khác là sử dụng trình điều khiển hạt nhân có thể truyền dữ liệu đến/từ một thiết bị khác, nhưng đưa ra các lỗi trên đường đi. Sau đó bạn có thể gắn thiết bị và sử dụng nó từ bất kỳ ứng dụng nào như thể nó là một đĩa bị lỗi. Trình điều khiển fsdisk là một ví dụ về điều này.

Ngoài ra còn có cơ sở hạ tầng tiêm lỗi đã được hợp nhất vào nhân Linux, mặc dù có thể bạn sẽ cần cấu hình lại hạt nhân để bật nó. Nó được ghi lại trong Documentation/fault-injection/fault-injection.txt. Điều này rất hữu ích để thử nghiệm mã hạt nhân.

Cũng có thể sử dụng SystemTap để truyền lỗi ở cấp hạt nhân. Xem The SCSI fault injection test và Kernel Fault injection using SystemTap.

Answer 2

Một cách đơn giản để thực hiện một đĩa SCSI biến mất với kernel 2.6 là:

echo 1 > /sys/bus/scsi/devices/H:B:T:L/delete 

(H: B: T: L là chủ nhà, xe buýt, mục tiêu, LUN). Để mô phỏng trường hợp chỉ đọc, bạn sẽ phải sử dụng các phương pháp tiêm lỗi mà mark4o đã đề cập.

Answer 3

Để thêm vào câu trả lời của mark4o, bạn cũng có thể sử dụng Trình ánh xạ thiết bị của Linux để tạo các thiết bị không thành công.

Device Mapper's delay device có thể được sử dụng để gửi đọc và ghi I/O của cùng một khối tới các thiết bị cơ bản khác nhau (nó cũng có thể làm trễ I/O như tên của nó). Thiết bị lỗi của thiết bị Mapper có thể được sử dụng để tạo ra các lỗi vĩnh viễn khi một khối cụ thể được truy cập. Bằng cách kết hợp cả hai, bạn có thể tạo một thiết bị mà ghi luôn luôn thất bại nhưng đọc luôn luôn thành công cho một khu vực nhất định.

Ở trên là một ví dụ phức tạp hơn về những gì được mô tả trong câu hỏi Simulate a faulty block device with read errors? (xem https://stackoverflow.com/a/1871029 cho ví dụ về Trình ánh xạ thiết bị đơn giản).

Ngoài ra còn có list of Linux disk fault injection mechanisms trên Special File that causes I/O error Câu hỏi về Unix & Linux.

Answer 4

Bạn có thể sử dụng mô-đun hạt nhân scsi_debug để mô phỏng đĩa RAM và hỗ trợ tất cả các lỗi SCSI với các tùy chọn opts và every_nth.

Vui lòng kiểm tra này http://sg.danny.cz/sg/sdebug26.html

Ví dụ về lỗi trung vào ngành 4656:

[fge@Gris-Laptop ~]$ sudo modprobe scsi_debug opts=2 every_nth=1 
[fge@Gris-Laptop ~]$ sudo dd if=/dev/sdb of=/dev/null 
dd: error reading ‘/dev/sdb’: Input/output error 
4656+0 records in 
4656+0 records out 
2383872 bytes (2.4 MB) copied, 0.021299 s, 112 MB/s 
[fge@Gris-Laptop ~]$ dmesg|tail 
[11201.454332] blk_update_request: critical medium error, dev sdb, sector 4656 
[11201.456292] sd 5:0:0:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 
[11201.456299] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current] 
[11201.456303] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error 
[11201.456308] sd 5:0:0:0: [sdb] CDB: Read(10) 28 00 00 00 12 30 00 00 08 00 
[11201.456312] blk_update_request: critical medium error, dev sdb, sector 4656 

Bạn có thể thay đổi các tùy chọn opts và every_nth trong thời gian chạy qua sysfs:

echo 2 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts 
echo 1 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts 

Answer 5

Linux kernel cung cấp một tính năng đẹp được gọi là “lỗi tiêm”

echo 1 > /sys/block/vdd/vdd2/make-it-fail 

Để thiết lập một số tùy chọn:

mkdir /debug 
mount debugfs /debug -t debugfs 
cd /debug/fail_make_request 
echo 10 > interval # interval 
echo 100 > probability # 100% probability 
echo -1 > times # how many times: -1 means no limit 

https://lxadm.com/Using_fault_injection

Answer 6

Người ta cũng có thể sử dụng phương pháp được cung cấp bởi các đĩa để làm thử nghiệm lỗi phương tiện truyền thông. SCSI có một lệnh WRITE LONG có thể được sử dụng để làm hỏng một khối bằng cách ghi dữ liệu với ECC không hợp lệ. SATA và NVMe cũng có các lệnh tương tự.

Đối với trường hợp phổ biến nhất (SATA), bạn có thể sử dụng hdparm với --make-bad-sector để sử dụng lệnh đó, bạn có thể sử dụng sg_write_long cho SCSI và NVMe bạn có thể dùng nvme-cli với ghi-uncor Tùy chọn.

Lợi thế lớn mà các lệnh này có trên các phương pháp tiêm khác là chúng cũng hoạt động giống như một ổ đĩa, với các tác động độ trễ đầy đủ và cũng phục hồi khi ghi vào khu vực đó bằng cách phân bổ lại. Điều này bao gồm cả các bộ đếm lỗi đi lên trong ổ đĩa.

Điểm bất lợi là nếu bạn làm điều này quá nhiều cho cùng một ổ đĩa, bộ đếm lỗi của nó sẽ tăng lên và SMART có thể gắn cờ đĩa xấu hoặc bạn có thể làm cạn kiệt bảng phân bổ lại. Vì vậy, sử dụng nó để kiểm tra thủ công, nhưng nếu bạn đang chạy nó trên thử nghiệm tự động không làm điều đó quá thường xuyên.