Re: Advanced Format SAT devices show incorrect physical block size

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

 



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.

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

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.

Also, is `sg_readcap -16` a proper test to determine whether the
device works as expected?
--
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