답변:
아니요, 데이터가 손실되었음을 의미하지는 않습니다. 이는 IO 시스템이 완료되기를 기다리는 동안 IRP (IO 요청 패킷)가 시간 초과되어 다시 시도되었음을 의미합니다. 스레드가 IO 작업을 시작하면 IO 관리자는 시스템을 통과 할 때 작업을 나타내는 IRP를 만듭니다.
IRP는 버퍼 / look-aside 목록에 초기 상태로 저장되므로 처음 실패했을 때 다시 시도 할 수 있습니다. 이는 트랜잭션 시스템에서 기대할 수있는 원 자성을 제공하므로 디스크에 손상되거나 불완전한 데이터가 많이 기록되지 않을 것이라는 확신을 가질 수 있습니다.
이 이벤트는 MPIO 실패시 완벽하게 이해됩니다. Windows가 SAN 스토리지에서 무언가를 읽거나 씁니다. 요청이 발송되고 동시에 케이블 중 하나를 SAN으로 절단했습니다. 해당 요청은 완료되지 않으므로 Windows는 요청을 다시 시도하지만 이번에는 요청이 다른 경로를 따릅니다.
이러한 이벤트는 디스크에 과부하가 걸리거나 실제로 느려질 때도 발생합니다. 이러한 메시지는 예약 된 백업 등과 일치하는 것을 알 수 있습니다. 디스크가 느리고 사용 중일 수 있으며 임의의 IRP 시간이 초과되어 다시 시도해야했습니다. IRP가 인터럽트 서비스 루틴, 지연된 프로 시저 호출 또는 기타 상황에 빠질 수 있습니다.
스택에 많은 IO 필터 드라이버가 있어이 문제를 악화시키는 것을 볼 수 있습니다.
이전 버전의 Windows에서 이와 같이이 동작이 발생하지 않았다는 것이 아니라 Microsoft가 Win8 / Server 2012에서 이러한 이벤트를 표시하기로 결정한 것입니다.
편집 : 커널 디버거를 사용하여 스레드의 미해결 IRP를 찾을 수 있습니다 : kd> !irp 1a2b3c4d. 여기서 이전 kd> !process 8f7d6c4a에는 해당 프로세스와 관련된 스레드와 관련된 모든 IRP를 나열 하는 명령 을 실행하여 해당 주소를 찾았습니다 . kd> !process 0 0실행중인 모든 프로세스를 나열합니다.
! irp 명령을 사용하여 IRP에 대한 정보를 나열하면 목록에서 IRP를 >가리 키기 때문에 IRP를 마지막으로 처리 한 드라이버를 쉽게 찾을 수 있습니다 . 그런 다음 해당 드라이버가 해당 IRP로 수행 한 작업에 대한 자세한 정보를 얻으려면 kd> !devobj 1a2b3c4d5e6f장치 오브젝트의 실제 주소 인 위치를 수행하십시오 .
그런 다음 kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA얻은 PrivateFdoData 구조의 주소를 사용하십시오.
이제 PrivateFdoData에서 얻은 AllTransferPacketsList 데이터 구조를 덤프 할 준비가되었습니다.
아이디어는 마지막으로 볼 때 IRP로 무엇을하고 있는지를 추적하고 있다는 것입니다. IRP가 너무 오랫동안 AWOL이면 시간이 초과되어 처음부터 다시 시도됩니다. 이것은 많은 것들, 심지어 미광 우주 광선으로 인해 발생할 수 있습니다. 그러나 중요한 것은 트랜잭션이 처음부터 재 시도되며 IO 관리자가 완료 할 때까지 완료된 것으로 간주되지 않는다는 것입니다.
아, 그리고 완전히 다른 웜 캔인 스레드에 무관 한 IO도 있습니다. :)
이 주제에 대한 자세한 내용을 보려면 Mark Russinovich (Margosis 등)의 Windows Internals 6th Edition 8 장 I / O System을 강력히 권장합니다.
** 편집 : ** 마침내이 오류에 대한 공식 KB를 찾았습니다. http://support.microsoft.com/kb/2819485/EN-US
IO 작업은 Windows가 종료 될 때까지 분당 한 번 8 번 재 시도해야합니다.
편집 : 약속대로 : http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
아니요, 다른 메시지가있을 수 있으며 데이터를 성공적으로 저장하지 못하면 응용 프로그램 계층 중 하나에서 예외가 발생합니다.
Windows Server 2012 (또는 Windows Server 2008 R2의 경우 핫픽스 2819485) 이전에는 이러한 시간 초과가 발생하면 시스템이 자동으로 다시 시도됩니다. 메시지의 목적은 이러한 발생에 대한 가시성을 높이는 것입니다. 용량 문제 또는 드라이버 결함을 나타낼 수 있으며 iSCSI의 경우 다른 운영 체제 결함으로 인해 지연이 발생할 수 있습니다.
외부 (직접 연결되지 않은) 스토리지의 경우 과거 일부 공급 업체는 시간 초과 값을 60 초로 늘 렸습니다. 그러나 iSCSI 초 기자와 같은 상위 계층 구성 요소에 의한 기본 재시도 횟수는 시스템이 장애 조치를 시작하기 전에 몇 분이 경과 할 수 있음을 의미합니다. 그것은 차선책 일 것입니다.
더 많은 정보 :
SCSI 미니 포트 드라이버의 레지스트리 항목
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
Microsoft는 storport.sys 작업에 대한 임계 값을 지정하는 기능을 제공하는 업데이트를 발표했습니다.
이 업데이트를 설치 한 후 스토리지에 대한 I / O 대기 시간이 임계 값 이상인 경우 이벤트를 기록 할 수 있습니다. 임계 값은 사용자가 설정할 수 있습니다. 이 작업은 어댑터 드라이버 수준에서 수행되므로 SAN에 성능 문제가 있는지 확인할 수 있습니다. 그런 다음 스토리지 공급 업체에 문의하여 문제를 해결할 수 있습니다.
참고 : 이 업데이트는 Windows 7 및 Windows Server 2008 R2에서 제공되었던 기능을 복원합니다. 기능이 활성화되면 임계 값은 100 나노초 (0.0001 밀리 초)로 측정됩니다. 또한 다음 값이 이벤트에 기록됩니다.
BuildIoDuration : MINIPORT 가이 요청에 대한 빌드 I / O 기능에 소비 한 시간 StartIoDuration : MINIPORT 가이 요청 에 대한 I / O 시작 기능에 소비 한 시간 DataTransferLength : 바이트 단위의 전송 크기
Windows Server 2012에서 Storport.sys 드라이버의 로깅 기능을 개선하는 업데이트
http://support.microsoft.com/kb/2819476
Windows 8 및 Windows Server 2012 누적 업데이트 : 2013 년 4 월
http://support.microsoft.com/kb/2822241