On Thu, 2014-11-06 at 17:08 +0000, David Laight wrote:
> From: Boaz Harrosh
> > On 11/06/2014 05:53 PM, Alan Stern wrote:
> > >> But just the simple case of read-capacity failure should we then?
> > >
> > > That's a separate question. As far as I know, the case you are
> > > describing has not come up.
> > >
> >
> > BTW: what we should do is when the partition parser at the block layer
> > see that the partition capacity as written in the partition-table is
> > bigger then the capacity reported for the device we can put a fat
> > message at dmesg with both sizes and user can decide.
>
> One possibility is to try to read the last sector of the actual
> partition. If it succeeds there are 2 possibilities:
These are USB devices (bridges) not well behaved SCSI devices. The last
time we tried to poke USB devices beyond their defined capacity (the USB
capacity off by one problem) the firmware on some crashed and we
eventually gave up. That's why, unless we can find simple, functional
heuristics for the kernel, it's safer to punt to userspace.
James
> 1) The disk is as bit as the partition table indicates.
> 2) The high bit(s) of the sector number have been masked.
> (or the disk locks up)
>
> In many cases the latter can be verified by reading the other sector.
> But if the media is new/erased then all the sectors will be 0xff
> and you'd have to do a write to ensure there was no sector aliasing.
>
> David
>
> NrybXǧv^){.n+{"{ay ʇڙ,jfhz w j:+vwjmzZ+ݢj"!
--
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
