[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]



>>>>> "Mike" == Mike Snitzer <snitzer redhat com> writes:

Mike> So are there drives like this?:
Mike> 1) don't support RSOC
Mike> 2) do support WRITE SAME
Mike> 3) do populate VPD page with either WRITE SAME w/ discard bit set
Mike>    or UNMAP?

Yes.

But again, the fundamental issue here is not the drives. It's the
controller firmware. I am not aware of a single SPI/SAS/FC drive that
does not support at least WRITE SAME(10).

For DIX and T10 PI I have a capabilities mask that each HBA driver fills
out that tells the sd driver what the controller can do. And this is
combined with whatever the drive reports to figure out whether integrity
protection can be enabled.

I have been contemplating doing something similar for "fancy" SCSI
commands. We could have a flag in the scsi host template that controls
whether the device supports WRITE SAME, EXTENDED COPY, etc. The
advantage being that we do the matching at discovery time instead of
once a WRITE SAME is issued.

This would also permit HBA drivers to toggle the feature on a per
instance basis. I.e. if "RAID controller firmware rev is lower than XYZ,
do not support WRITE SAME".

I'll do a PoC later today...

-- 
Martin K. Petersen	Oracle Linux Engineering


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]