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

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

 



>>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> 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

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux