Re: sd_mod or usb-storage fails to read a single good block (was: ehci_hcd fails to read a single good block)

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

 



Alan Stern wrote:
> On Fri, 13 Apr 2012, Norman Diamond wrote:
>> You THOUGHT you knew in advance that a particular bridge is known to have the overreporting but, where in fact in some secret revisions it doesn't and in some secret revisions we're not quite sure, missing a log and missing a test sample for further testing.  How can we be sure that other bridge manufacturers don't also make secret revisions?
> 
> In fact we don't know.  But that's not a good enough reason to risk breaking existing systems.  When we encounter bridges whose behavior has changed, we can update the quirk entries.

That's not a good enough reason to cause known breakage in newer existing systems, but I agree that updating the quirk entries helps solve it.

> (Even that isn't as cautious as I'd like.  If the device behavior has changed then maybe the old devices won't handle reading beyond the end of the drive.  But I can't think of anything safer.)

Well, if the reported capacity isn't a multiple of 63 and if no existing partition includes the last reported block then it seems comparatively safe to decrement the reported size, but as you pointed out, we can't really be sure what the existing partitions are (non-DOS tables etc.).  But a multiple of 63 still seems like a relatively safe heuristic, comparatively speaking.  But not always, as you pointed out, and as I'll detail below.

>>> Not all disks have an even number of blocks.  That heuristic really isn't a very good one -- its only benefit is that it works okay for the one case where it is currently used.
>> 
>> If you do mean disks, then we can improve that heuristic.  Forget about the 126 that I mentioned last time, but go with the 63 because we know why that factor is very common in drives that had physical 512 byte sectors.  For drives being made these days with physical 4096 byte sectors, obviously the number of logical 512 byte sectors is going to be even just as it is with the one device that presently has the HEURISTICS flag.
> 
> Don't modern disks have some arbitrary numbers of blocks reserved by the manufacturer?

Of course, for relocations of bad blocks and for some other purposes too.  They don't have LBAs.  They aren't included in the reported capacity.  They aren't relevant to this discussion.

(I assume that my drive with bad blocks has already used all of its blocks that had been reserved for relocations.)

> I forget the acronym for this, but it seems reasonable that it could cause the capacity not to be a multiple of 63.

No need to worry about that  ^_^

I have a drive made in 1992, with no currently observed bad blocks, with the following identifications:
C*H*S = 1579*16*63 = 1591632
LBA capacity = 1592568
(Today I only have to manhandle a fragile SATA-to-PATA adapter, plus eSATA-to-SATA cable and SATA power supply, to get genuine ATA identifications.)

So yes indeed the capacity might not be a multiple of 63.  63 is very common for obvious reasons, but not universal.  Also of course 63 isn't likely on current drives with 4096 byte physical sectors, which emulate a capacity in 512 byte sectors that will obviously be a multiple of 8.  But in all of these cases the current heuristic for even numbers still succeeds.  So respecting a report of a multiple of 63, and if it isn't a multiple of 63 then falling back to respecting a report of a multiple of 2, seems like a good bet for doing a test read of the last reported sector.

>> If you mean other USB devices that emulate disks, then of course there's a wider range of possibilities. [...]  So yeah, I have no suggestion for devices other than actual disks being connected through USB to [S]ATA bridges.
> 
> The problem is that we don't always know which devices are USB-(S)ATA bridges and which aren't.  The quirk entries may not record that information.

usb.ids records a bunch of them.  Though of course that's not an "always".
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux