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]

 



>>>>> "Mikulas" == Mikulas Patocka <mpatocka@xxxxxxxxxx> writes:

Mikulas> Propagating the limits up the tree won't work anyway because of
Mikulas> a race condition. Think of this case:

Mikulas> 1. We test queue limits and find out that the device supports
Mikulas>    WRITE_SAME
Mikulas> 2. We build a WRITE_SAME bio to be submitted.
Mikulas> 3. The user reconfigures a device so that it no longer supports
Mikulas>    WRITE_SAME
Mikulas> (for example, he adds a snapshot or converts linear volume to a
Mikulas> mirror).
Mikulas> 4. We submit the bio that we built in step 2.
Mikulas> 5. The bio fails.

The existing "fall back to writes if write same fails" mechanism isn't
going away. We absolutely need that.

The principal headache is caused by host adapters that perform SCSI-ATA
or SCSI-<internal RAID implementation> translation and which do not
correctly fail a WRITE SAME command that we send down to the disk.

Based on heuristics from querying the target we expect WRITE SAME to
succeed so we enable it. But for whatever reason the controller is not
able to handle the command. Most controllers/drivers will fail the
command correctly and we'll disable WRITE SAME and fall back to manually
zeroing. Some controllers, however, hang or fail the I/O in a way in
which we do not pick up it's a WRITE SAME problem.

The other headache is what happens if a stacking driver gets -EIO or
-EREMOTEIO on a WRITE SAME request. That's what Mike was trying to fix
with his patch. Maybe it would make sense for us to use -EINVAL or
something similar to single out the ILLEGAL REQUEST case. While
-EREMOTEIO specifically calls out for "no retry" it might be helpful to
indicate that we're dealing with an unsupported command. That way DM or
MD can reconfigure themselves accordingly.

-- 
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