Re: Advanced Format SAT devices show incorrect physical block size

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

 



On Tue, 10 Jan 2017, Dainius Masiliūnas wrote:

> On Tue, Jan 10, 2017 at 9:00 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > It is used for preventing the kernel from issuing a READ CAPACITY(16)
> > command to the device.  Normally the kernel would do this if the reply
> > to READ CAPACITY(10) indicated there were more than 2^32 blocks (about
> > 2 TB).
> 
> Ah, OK, that makes sense. Though that's still not a proper solution,
> and if anything it's confusing for the users: if they plug in a >2 TiB
> drive and it breaks, the user will assume that it's the fault of the
> drive and not the USB case, or that the case is incapable of handling
> such large drives, whereas the true reason is completely different.

I'm not sure what you mean.  If the quirk flag is set and the user 
plugs in a >2-TB drive, it won't break.  It just won't report the 
correct size, but at least it will continue to work in a degraded 
fashion.

> > In theory, I suppose we could change the kernel so that it would
> > default to READ CAPACITY(16) for devices that report a SCSI level >= 3,
> > or something along those lines.  In general we hesitate to make changes
> > of this sort, because they almost always end up breaking _some_
> > devices -- and if that happens then the change is reverted, with no
> > exceptions.  Linus has a very strict rule about not breaking working
> > systems.
> 
> Well, the problems are 1) we don't really know how many such
> misbehaving drives there are, since only those with >2 TiB drives
> experience it, thus it's hard to know what effect such change would
> have, and 2) there is no way to make the kernel output the true value
> even if you know your drive is working fine.

We could add that easily enough: a usb-storage quirk to set the 
NEEDS_CAP16 flag.  But it would be better if this wasn't necessary.

> And when a drive breaks due to the 16 command, is there a way to
> revive it, perhaps by trying to reconnect? That would allow the kernel
> to try it first, see that it failed after that command was sent, then
> issue a warning in the log saying that this device should have a
> quirk, reset and continue with the quirk applied.

I'm not sure what you mean by "trying to reconnect".  The recovery
method most likely to work is to unplug the USB cable and then
re-attach it.  Issuing a reset might work in some cases and not in 
others; we have seen examples of devices that crash extremely hard when 
given something they don't know how to handle.

> Also, is `sg_readcap -16` a proper test to determine whether the
> device works as expected?

You mean, to determine whether the device can handle a READ 
CAPACITY(16) command?  Yes, since that is the command it sends.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux