https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236042
--- Comment #13 from Dexuan Cui <de...@microsoft.com> --- (In reply to Michael from comment #11) When you see the SCSI errors, can the live backup procedure succeed? Do you notice any instability issue (e.g.hang/panic)? Do you notice any data corruption issue (e.g. the back-up procedure says it succeeded, but later you may find that the data is not really consistently backed up, i.e. 'fsck' may run while you think it should not)? If the backup procedure still succeeds, and you never notice any real issue, then I think it should be safe to ignore the SCSI error messages -- if we want to get rid of the messages, it looks sys/dev/hyperv/utilities/hv_snapshot.c is not an issue -- it looks we need to improve sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c and/or the other part of SCSI subsystem. Linux VM on Hyper-V shows the same/similar messages when Hyper-V live backup is being performed (at least this was the case in June 2017): sd 2:0:0:0: [storvsc] Sense Key : Unit Attention [current] sd 2:0:0:0: [storvsc] Add. Sense: Changed operating definition sd 2:0:0:0: Warning! Received an indication that the operating parameters on this target have changed. The Linux SCSI layer does not automatically adjust these parameters. These messages in a Linux VM can be seen even if the back-up is successful, so it looks people just ignore the messages in Linux. The messages are caused as a result of the way how Hyper-V live-backup works: usually the VM's .vhdx file has a block size of 32MB, and during the live-backup procedure IIRC it looks a temporary .avhdx of a 2MB block size is generated and the host returns sense key "Unit Attention" with asc 0x3f and ascq 0x2 (Changed Operating Definition); the host sends "Unit Attention" because the backing VHD block size has changed after checkpoint or backup and this results in a change in the granularity of the UNMAP. Linux SCSI layer can deal with the following asc 0x3f on Unit Attention: ascq 0x3 (Inquiry Data Has Changed) ascq 0xe (Reported Luns Data Has Changed) However ascq 0x2 is ignored. The SCSI won’t know the UNMAP granularity change, it will run at probably slower UNMAP but won’t affect other parts. Note: I excerpted the above details from a 2017 email discussing the SCSI errors in a Linux VM on Hyper-V. My understanding is that the messages can be safely ignored in Linux, but I'm not sure about FreeBSD, as the SCSI subsystem in FreeBSD may handle the sense info in a different manner. I have moved on to different projects, so I am sorry I can not follow this up... I hope someone would find the info I shared here is useful, in case something has to be done in FreeBSD VM. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
