Tôi có lưỡi dao máy chủ được cấu hình IO đa luồng 2012 hiển thị các cảnh báo như sau trong lỗi đường dẫn MPIO:
Hoạt động IO tại địa chỉ khối logic 0 cho Đĩa 7 đã được thử lại.
Tôi biết điều gì gây ra cảnh báo xảy ra vì vậy tôi không tìm kiếm nguyên nhân nhưng thông điệp này thực sự có ý nghĩa gì?
Có nghĩa là nếu IO này là một hoạt động ghi thì máy chủ thực sự bị mất dữ liệu mà nó đang cố ghi?
Cảm ơn bạn cho bất kỳ ánh sáng bạn có thể làm sáng tỏ ý nghĩa của thông điệp cảnh báo này.
Câu trả lời:
Không, điều đó không có nghĩa là dữ liệu bị mất. Điều đó đơn giản có nghĩa là IRP (Gói yêu cầu IO) đã hết thời gian trong khi Hệ thống IO chờ nó hoàn thành và do đó, nó đã được thử lại. Khi một luồng bắt đầu bất kỳ hoạt động IO nào, trình quản lý IO tạo IRP để thể hiện hoạt động khi nó đi qua hệ thống.
IRP được lưu trữ ở trạng thái ban đầu trong danh sách bộ đệm / nhìn sang một bên, để nó có thể được thử lại nếu lần đầu tiên thất bại. Điều đó cung cấp tính nguyên tử mà người ta mong đợi từ bất kỳ hệ thống giao dịch nào để chúng tôi có thể tin tưởng hơn rằng bạn sẽ không nhận được một loạt dữ liệu bị hỏng hoặc không đầy đủ được ghi vào đĩa của bạn.
Sự kiện này có ý nghĩa hoàn hảo trong trường hợp thất bại MPIO. Nói rằng Windows sẽ đọc hoặc viết một cái gì đó từ bộ lưu trữ SAN. Yêu cầu được gửi đi, và cùng lúc đó, tôi cắt một trong các dây cáp cho SAN. Yêu cầu đó sẽ không bao giờ hoàn thành và vì vậy Windows sẽ thử lại yêu cầu, chỉ lần này yêu cầu sẽ đi theo con đường khác.
Những sự kiện này cũng xảy ra khi các đĩa bị quá tải hoặc chỉ thực sự chậm. Bạn có thể nhận thấy những tin nhắn này trùng với các bản sao lưu theo lịch, v.v. Đĩa có thể chậm và bận, và một số IRP ngẫu nhiên đã hết thời gian và phải thử lại. IRP có thể bị kẹt trong một thói quen dịch vụ bị gián đoạn, hoặc một cuộc gọi thủ tục bị trì hoãn, hoặc bất cứ điều gì.
Tôi có thể thấy có rất nhiều trình điều khiển bộ lọc IO trong ngăn xếp của bạn cũng làm trầm trọng thêm vấn đề này.
Không phải hành vi này đã không xảy ra như thế này trong các phiên bản Windows trước, chỉ là Microsoft rõ ràng đã quyết định xuất hiện những sự kiện này trong Win8 / Server 2012.
Chỉnh sửa: Bạn có thể tìm thấy các IRP nổi bật của một luồng với trình gỡ lỗi kernel : kd> !irp 1a2b3c4d, nơi trước đây bạn đã tìm thấy địa chỉ đó bằng cách phát lệnh kd> !process 8f7d6c4asẽ liệt kê tất cả các IRP được liên kết với các luồng liên quan đến quá trình đó. kd> !process 0 0để liệt kê tất cả các quy trình đang chạy.
Khi bạn liệt kê thông tin về IRP bằng lệnh! Irp, bạn có thể dễ dàng phát hiện trình điều khiển nào đã xử lý IRP lần cuối bởi vì nó sẽ >chỉ đến nó trong danh sách. Sau đó, để có thêm thông tin về những gì trình điều khiển đó đã làm với IRP đó, hãy kd> !devobj 1a2b3c4d5e6fthực hiện địa chỉ thực sự của đối tượng thiết bị.
Sau đó, kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAsử dụng địa chỉ của cấu trúc PrivateFdoData mà bạn có.
Bây giờ bạn đã sẵn sàng kết xuất cấu trúc dữ liệu AllTransferPacketsList mà bạn nhận được từ PrivateFdoData.
Ý tưởng là, bạn đang theo dõi những gì trình điều khiển đã làm gì với IRP lần cuối cùng được nhìn thấy. Nếu IRP là AWOL quá lâu, nó đã hết thời gian và thử lại từ đầu. Điều này có thể được gây ra bởi rất nhiều thứ ... thậm chí là một tia vũ trụ đi lạc. Nhưng điều quan trọng là giao dịch sẽ được thử lại từ đầu và nó sẽ không được coi là hoàn thành cho đến khi người quản lý IO nói.
Ồ, và còn có IO không biết chủ đề, một loại giun hoàn toàn khác. :)
Để đọc thêm về chủ đề này, tôi đánh giá cao chương 8, Hệ thống I / O, của Windows Internals phiên bản 6, từ Mark Russinovich, Margosis, et al.
** Chỉnh sửa: ** Cuối cùng tôi đã tìm thấy KB chính thức cho lỗi này: http://support.microsoft.com/kb/2819485/EN-US
Hoạt động IO nên được thử lại 8 lần, mỗi lần một phút, cho đến khi Windows bỏ cuộc.
Chỉnh sửa: Như đã hứa: http://bloss.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
Không, sẽ có một thông báo khác và (hy vọng) một trong các lớp ứng dụng sẽ đưa ra một ngoại lệ nếu không lưu thành công dữ liệu.
Trước Windows Server 2012 (hoặc hotfix 2819485 nếu trên Windows Server 2008 R2), hệ thống sẽ âm thầm thử lại khi những khoảng thời gian này xảy ra. Mục đích của thông điệp là tăng khả năng hiển thị về những sự kiện này. Chúng có thể chỉ ra vấn đề về dung lượng hoặc lỗi trình điều khiển và trong trường hợp iSCSI, các lỗi hệ điều hành khác có thể quy cho sự chậm trễ.
Trong trường hợp lưu trữ bên ngoài (không gắn trực tiếp), một số nhà cung cấp trong quá khứ đã tăng giá trị thời gian chờ, ví dụ lên 60 giây. Tuy nhiên, với số lần thử lại mặc định của các thành phần lớp cao hơn như bộ khởi tạo iSCSI, điều này có thể có nghĩa là vài phút có thể trôi qua trước khi hệ thống khởi tạo chuyển đổi dự phòng. Đó rõ ràng sẽ là hành vi tối ưu.
Thêm thông tin:
Các mục đăng ký cho Trình điều khiển Miniport SCSI http://msdn.microsoft.com/en-us/l Library / windows / hardware / ff563970% 28v = vs85% 29.aspx
Microsoft đã phát hành một bản cập nhật cung cấp khả năng chỉ định ngưỡng cho các hoạt động của repositoryport.sys.
Sau khi bạn cài đặt bản cập nhật này, bạn có thể đăng nhập một sự kiện khi thời gian trễ để I / O lưu trữ bằng hoặc lớn hơn một ngưỡng. Giá trị ngưỡng có thể được đặt bởi người dùng. Hoạt động này được thực hiện ở cấp Trình điều khiển Bộ điều hợp để bạn có thể xem liệu có vấn đề về hiệu suất trên SAN hay không. Sau đó, bạn có thể liên hệ với một nhà cung cấp lưu trữ để giải quyết vấn đề.
Lưu ý: Bản cập nhật này khôi phục chức năng được cung cấp trong Windows 7 và Windows Server 2008 R2. Khi chức năng được bật, giá trị ngưỡng được đo bằng 100 nano giây (0,0001 mili giây). Ngoài ra, các giá trị sau được ghi lại trong sự kiện:
BuildIoDuration : Khoảng thời gian mà MINIPORT đã dành cho chức năng I / O xây dựng cho yêu cầu này StartIoDuration : Khoảng thời gian mà MINIPORT đã dành cho chức năng I / O bắt đầu cho yêu cầu này DataTransferLpm : Kích thước chuyển theo byte
Cập nhật giúp cải thiện khả năng ghi nhật ký của trình điều khiển Storport.sys trong Windows Server 2012
http://support.microsoft.com/kb/2819476
Cập nhật tích lũy Windows 8 và Windows Server 2012: Tháng 4 năm 2013
http://support.microsoft.com/kb/2822241
Có thể là một bài viết muộn, nhưng tôi đã thấy rằng nó có thể được gây ra với VSS. Chúng tôi có một khách hàng đang chạy veeam nhưng đã quên tắt máy chủ windows sao lưu (đĩa đã bị xóa) Nó gây ra vô số vấn đề và lỗi này là lỗi chính.
Dừng lại sao lưu và wham, không có lỗi.