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]

On Fri, 13 Apr 2012, Norman Diamond wrote:

> Now you're the one being naive  ^_^
> 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.

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

> OK.  Then we still need something more than the new TEST_CAPACITY
> flag trying to read the last reported block to see if the block
> exists or not.  In cases marked as FIX_CAPACITY we ought to see if an
> existing partition ends in the last reported block -- if it doesn't
> then we can truncate the drive and no partition gets truncated, but
> if it does then maybe we should consider changing the device's flag

This is getting too complicated.  Not all storage devices have
partition tables.  Not all partition tables use the conventional DOS
format.  And by the time the partition-table parsing code runs, it may
be too late to change the recorded capacity -- I'm not sure about that.

> > 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?  I forget the acronym for this, but it seems
reasonable that it could cause the capacity not to be a multiple of 63.

> If you mean other USB devices that emulate disks, then of course
> there's a wider range of possibilities.  The ATA identification might
> assert any number of emulated sectors per emulated track, etc.  And
> even when the device states its correct number of LBA blocks (not
> having been altered by fraudsters to sell a fake high capacity device
> in eBay), the vendor might have preformatted it with a partition
> extending past the end of the device.  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

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

[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photos]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux