From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Boaz Harrosh' <openosd@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Boaz Harrosh <boaz@plexistor.com>,
Christoph Hellwig <hch@infradead.org>,
"Dale R. Worley" <worley@alum.mit.edu>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: Large disk drives
Date: Thu, 06 Nov 2014 18:18:07 +0100 [thread overview]
Message-ID: <1415294287.10617.14.camel@jarvis.quadriga.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9EA6C1@AcuExch.aculab.com>
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\x1dʇڙ,j\afhz\x1ew\fj:+vwjm\azZ+ݢj"!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-11-06 17:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 21:06 Large disk drives Dale R. Worley
2014-11-04 7:52 ` James Bottomley
[not found] ` <1415087562.2351.3.camel-7O4RPy5TklLPRNG96csxHf8+0UxHXcjY@public.gmane.org>
2014-11-04 16:14 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1411041112010.966-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2014-11-05 15:51 ` Dale R. Worley
2014-11-05 16:07 ` James Bottomley
2014-11-05 16:34 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1411051130470.1531-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2014-11-05 18:53 ` Boaz Harrosh
2014-11-05 19:30 ` Christoph Hellwig
[not found] ` <20141105193045.GA13265-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-11-06 10:30 ` James Bottomley
2014-11-06 14:33 ` Boaz Harrosh
[not found] ` <545B86AC.3080704-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
2014-11-06 15:53 ` Alan Stern
2014-11-06 16:43 ` Boaz Harrosh
[not found] ` <545BA52F.6050205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-06 17:08 ` David Laight
2014-11-06 17:18 ` James Bottomley [this message]
2014-11-06 15:54 ` James Bottomley
2014-11-06 16:34 ` Boaz Harrosh
2014-11-06 16:59 ` Alan Stern
2014-11-06 19:23 ` Dale R. Worley
2014-11-06 20:16 ` Alan Stern
2014-11-05 19:15 ` Theodore Ts'o
[not found] ` <20141105191505.GF27083-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-11-06 19:17 ` Dale R. Worley
2014-11-05 23:30 ` Dale R. Worley
2014-11-06 17:47 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2014-11-07 4:53 Norman Diamond
[not found] ` <533357.25557.qm-303aDswoEIZ5hgrKqgaBcEyFvBl6snHEEwWAM/ix52Y@public.gmane.org>
2014-11-07 10:03 ` David Laight
2014-11-08 0:35 ` Norman Diamond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1415294287.10617.14.camel@jarvis.quadriga.com \
--to=james.bottomley@hansenpartnership.com \
--cc=David.Laight@ACULAB.COM \
--cc=boaz@plexistor.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=openosd@gmail.com \
--cc=stern@rowland.harvard.edu \
--cc=worley@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox