From: Boaz Harrosh <bharrosh-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
To: dgilbert-qazKcTl6WRFWk0Htik3J/w@public.gmane.org
Cc: Alan Stern
<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
Luciano Rocha <luciano-YWehAnL2kLNBDgjK7y7TUQ@public.gmane.org>,
James Bottomley
<James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>,
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
Linux-Kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
USB list <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
SCSI development list
<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: usb hdd problems with 2.6.27.2
Date: Mon, 27 Oct 2008 17:08:54 +0200 [thread overview]
Message-ID: <4905D986.6050001@panasas.com> (raw)
In-Reply-To: <4905D68D.7030407-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
Douglas Gilbert wrote:
>
> Since the READ CAPACITY "off by one" error is so common,
> perhaps drivers such as usb-storage could have a hook to
> do a pseudo READ CAPACITY. Then if the capacity value
> looked odd (in both senses) the driver could do an IO to
> the suspect block and if that failed decrement the capacity
> value passed back to the mid level.
> Put another way, why don't these defective devices trip up
> another OS?
>
Window$ never reads the last sector unless it is actually written
to. I had such a device it got stuck when I wrote to the
last sector.
> BTW a single disk in RAID 0 (seen on a HP E200 controller)
> has a shortened capacity value seen in the midlevel on the
> corresponding logical drive. That missing chunk is probably
> where the RAID controller puts its control information.
> Anyway, playing with the capacity value returned by READ
> CAPACITY certainly has a precedent.
>
>> Later on the system tries to read the contents of what it thinks is the
>> last sector:
>
> I know that happens but it seems strange that upper levels
> are reading a block that has never been written to. Read ahead?
>
That would be udev or hald, I can't remember which. It is a special Linux
fixture. ;)
> Doug Gilbert
>
>
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <bharrosh@panasas.com>
To: dgilbert@interlog.com
Cc: Alan Stern <stern@rowland.harvard.edu>,
Luciano Rocha <luciano@eurotux.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: usb hdd problems with 2.6.27.2
Date: Mon, 27 Oct 2008 17:08:54 +0200 [thread overview]
Message-ID: <4905D986.6050001@panasas.com> (raw)
In-Reply-To: <4905D68D.7030407@interlog.com>
Douglas Gilbert wrote:
>
> Since the READ CAPACITY "off by one" error is so common,
> perhaps drivers such as usb-storage could have a hook to
> do a pseudo READ CAPACITY. Then if the capacity value
> looked odd (in both senses) the driver could do an IO to
> the suspect block and if that failed decrement the capacity
> value passed back to the mid level.
> Put another way, why don't these defective devices trip up
> another OS?
>
Window$ never reads the last sector unless it is actually written
to. I had such a device it got stuck when I wrote to the
last sector.
> BTW a single disk in RAID 0 (seen on a HP E200 controller)
> has a shortened capacity value seen in the midlevel on the
> corresponding logical drive. That missing chunk is probably
> where the RAID controller puts its control information.
> Anyway, playing with the capacity value returned by READ
> CAPACITY certainly has a precedent.
>
>> Later on the system tries to read the contents of what it thinks is the
>> last sector:
>
> I know that happens but it seems strange that upper levels
> are reading a block that has never been written to. Read ahead?
>
That would be udev or hald, I can't remember which. It is a special Linux
fixture. ;)
> Doug Gilbert
>
>
Boaz
next prev parent reply other threads:[~2008-10-27 15:08 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 16:22 usb hdd problems with 2.6.27.2 Luciano Rocha
2008-10-25 19:25 ` Rafael J. Wysocki
[not found] ` <200810252125.44184.rjw-KKrjLPT3xs0@public.gmane.org>
2008-10-25 19:50 ` Alan Stern
2008-10-25 19:50 ` Alan Stern
2008-10-25 20:11 ` James Bottomley
2008-10-26 14:05 ` Luciano Rocha
2008-10-27 11:14 ` Luciano Rocha
2008-10-27 11:28 ` Luciano Rocha
2008-10-27 11:28 ` Luciano Rocha
[not found] ` <20081027112803.GA4398-oEplIgxCSygGFt9iVWuREaMaJEuR8uiQ@public.gmane.org>
2008-10-27 14:24 ` Alan Stern
2008-10-27 14:24 ` Alan Stern
2008-10-27 14:56 ` Douglas Gilbert
[not found] ` <4905D68D.7030407-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2008-10-27 15:08 ` Boaz Harrosh [this message]
2008-10-27 15:08 ` Boaz Harrosh
[not found] ` <4905D986.6050001-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
2008-10-27 16:26 ` Kay Sievers
2008-10-27 16:26 ` Kay Sievers
2008-10-27 15:25 ` Alan Stern
2008-10-27 15:33 ` James Bottomley
2008-10-27 15:18 ` Luciano Rocha
2008-10-27 15:18 ` Luciano Rocha
2008-10-27 15:38 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0810271134530.15462-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2008-10-27 16:53 ` Luciano Rocha
2008-10-27 16:53 ` Luciano Rocha
[not found] ` <20081027165306.GA3875-oEplIgxCSygGFt9iVWuREaMaJEuR8uiQ@public.gmane.org>
2008-10-27 20:10 ` Alan Stern
2008-10-27 20:10 ` Alan Stern
2008-10-28 16:37 ` Luciano Rocha
2008-10-28 16:37 ` Luciano Rocha
[not found] ` <20081028163722.GA4374-oEplIgxCSygGFt9iVWuREaMaJEuR8uiQ@public.gmane.org>
2008-10-28 17:38 ` Alan Stern
2008-10-28 17:38 ` Alan Stern
2008-11-03 15:52 ` Luciano Rocha
2008-11-03 15:52 ` Luciano Rocha
[not found] ` <20081103155254.GA3368-oEplIgxCSygGFt9iVWuREaMaJEuR8uiQ@public.gmane.org>
2008-11-03 19:46 ` Alan Stern
2008-11-03 19:46 ` Alan Stern
2008-11-05 10:26 ` Luciano Rocha
2008-11-05 10:26 ` Luciano Rocha
2008-11-05 16:51 ` Alan Stern
2008-11-13 17:10 ` Luciano Rocha
2008-10-27 20:36 ` Alan Stern
2008-10-27 20:36 ` Alan Stern
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=4905D986.6050001@panasas.com \
--to=bharrosh-c4p08nqkorlbdgjk7y7tuq@public.gmane.org \
--cc=James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
--cc=dgilbert-qazKcTl6WRFWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luciano-YWehAnL2kLNBDgjK7y7TUQ@public.gmane.org \
--cc=rjw-KKrjLPT3xs0@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.