From: David Laight
>
> From: Norman Diamond
> ...
>> By the way, I've seen some USB bridges that lie about whether they
>> performed various SAT commands (ATA passthrough), but told the truth
>> about performing an ATA IDENTIFY DEVICE through SAT. So we could attempt
>> ATA passthrough with a
From: Norman Diamond
...
> By the way, I've seen some USB bridges that lie about whether they
> performed various SAT commands (ATA passthrough), but told the truth
> about performing an ATA IDENTIFY DEVICE through SAT. So we could attempt
> ATA passthrough with an IDENTIFY DEVICE command, and if
If READ_CAPACITY_10 returns something that looks valid but might be off
by a multiple of 2TB, and READ_CAPACITY_16 fails, what do we really want
to do when we read the partition table?
If the partition table indicates that everything fits in the capacity
returned by READ_CAPACITY_10, great, it is
On Thu, 6 Nov 2014, Dale R. Worley wrote:
> There is one thing that seems like it might be a problem: We have to
> ensure that the SCSI driver can read the partition tables (in the
> standard locations) even if it doesn't know how big the disk is.
A DOS partition table is stored in the first 512
> From: James Bottomley
>
> We really don't want to make the decision within the kernel of whether
> we believe the partition size or the disk capacity. For these disk
> problems we need it to be the former, but if we choose that always,
> we'll get weird results on mispartitioned devices.
>
>
> From: "Theodore Ts'o"
>
> On Wed, Nov 05, 2014 at 05:07:48PM +0100, James Bottomley wrote:
> >
> > OK, but I still don't understand how windows gets the partition table on
> > there in the first place ... that must surely be some sort of guess the
> > disk size hack.
>
> 99% of the time the p
On Wed, 5 Nov 2014, Dale R. Worley wrote:
> > From: Alan Stern
>
> > I posted a patch to allow the user to override the reported capacity:
> >
> > http://marc.info/?l=linux-scsi&m=140993840113445&w=2
>
> I see the patch, and I feel confident I could install it if I needed
> to. What comma
On Thu, 2014-11-06 at 17:08 +, 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 com
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
On Thu, 6 Nov 2014, Boaz Harrosh wrote:
> On 11/06/2014 05:54 PM, James Bottomley wrote:
> >
> > We don't have a failure. This is the problem. Determining that a
> > problem exists
> >
>
> OK Sorry. I assumed the bridge is smart enough to do nothing,
>
> ie READ_CAPACITY_10 is passed as is
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
On 11/06/2014 05:54 PM, James Bottomley wrote:
>
> We don't have a failure. This is the problem. Determining that a
> problem exists
>
OK Sorry. I assumed the bridge is smart enough to do nothing,
ie READ_CAPACITY_10 is passed as is via sata to the device that
actually supports READ_CAPACITY
On Thu, 6 Nov 2014, Boaz Harrosh wrote:
> On 11/06/2014 12:30 PM, James Bottomley wrote:
> > We really don't want to make the decision within the kernel of whether
> > we believe the partition size or the disk capacity. For these disk
> > problems we need it to be the former, but if we choose t
On Thu, 2014-11-06 at 16:33 +0200, Boaz Harrosh wrote:
> On 11/06/2014 12:30 PM, James Bottomley wrote:
> > On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
> >> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> Sorry, meant to. In principle I'm OK with this as the leve
On 11/06/2014 12:30 PM, James Bottomley wrote:
> On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
>> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
Sorry, meant to. In principle I'm OK with this as the lever for the
hack (largely because it means we don't need to
On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> > > Sorry, meant to. In principle I'm OK with this as the lever for the
> > > hack (largely because it means we don't need to do anything) but will
> > > the distributions su
> From: Alan Stern
> I posted a patch to allow the user to override the reported capacity:
>
> http://marc.info/?l=linux-scsi&m=140993840113445&w=2
I see the patch, and I feel confident I could install it if I needed
to. What command do I execute to "write to the capacity_override
attrib
On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
> > Sorry, meant to. In principle I'm OK with this as the lever for the
> > hack (largely because it means we don't need to do anything) but will
> > the distributions support it?
>
> While I can't speak for the distributions, it's reaso
On Wed, Nov 05, 2014 at 05:07:48PM +0100, James Bottomley wrote:
>
> OK, but I still don't understand how windows gets the partition table on
> there in the first place ... that must surely be some sort of guess the
> disk size hack.
99% of the time the partition table was provided by the drive
m
On 11/05/2014 06:34 PM, Alan Stern wrote:
<>
>
> It's simpler than that: The drive is attached directly to the computer
> (i.e., via SATA rather than USB) when the partition table is created.
> With no USB-SATA bridge chip to mess things up, there's no problem
> determining the correct capacity.
On Wed, 5 Nov 2014, James Bottomley wrote:
> On Tue, 2014-11-04 at 11:14 -0500, Alan Stern wrote:
> > On Tue, 4 Nov 2014, James Bottomley wrote:
> >
> > > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > > > Was there any resolution as to ho
On Tue, 2014-11-04 at 11:14 -0500, Alan Stern wrote:
> On Tue, 4 Nov 2014, James Bottomley wrote:
>
> > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > > Was there any resolution as to how large disk drives would be handled
> > > if their interface
> Was there any resolution as to how large disk drives would be handled
> > > if their interface did not support the "capacity" request that would
> > > tell how large they were?
> >
> > Realistically no ... unless someone comes up with a reliable heuristi
On Tue, 4 Nov 2014, James Bottomley wrote:
> On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> > Was there any resolution as to how large disk drives would be handled
> > if their interface did not support the "capacity" request that would
> > tell how larg
On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote:
> Was there any resolution as to how large disk drives would be handled
> if their interface did not support the "capacity" request that would
> tell how large they were?
Realistically no ... unless someone comes
Was there any resolution as to how large disk drives would be handled
if their interface did not support the "capacity" request that would
tell how large they were?
Or as an alternative, is there any way to avoid buying USB-SCSI
interfaces that do not support the large-capaci
26 matches
Mail list logo
