All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Subject: Re: Checking a USB drive's capacity
Date: Mon, 22 Dec 2008 22:51:39 -0600	[thread overview]
Message-ID: <49506E5B.5090604@shaw.ca> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0812181641540.2217-100000@iolanthe.rowland.org>

Alan Stern wrote:
> Jens:
> 
> As you may know, there are plenty of USB mass-storage devices that
> respond incorrectly to READ CAPACITY: They report the total number of
> blocks instead of the highest block number.  As a result, the kernel 
> thinks the drive has one more sector than it really does.
> 
> So far we have dealt with this problem by means of a blacklist, but
> this gets more and more unsatisfactory all the time.  We haven't been
> able to find any other way to cope, since a few devices are so badly
> behaved that they crash hard when you try to access the nonexistent
> "last" sector, requiring a replug or power cycle.
> 
> My new idea is to keep in the blacklist only those devices which do
> crash -- a relatively small number.  Everything else we should be able
> to detect safely at runtime, by testing if it's possible to read the
> last sector.
> 
> The question is, how and where?  The logical place for testing the
> capacity is near the end of sd_read_capacity().  However this code runs
> before any media accesses have occurred; the drive might not even be
> spun up yet.  Not to mention that it seems strange to read the last
> sector before reading the first!

It seems to me that the safest solution would be to mark USB storage 
devices as unsafe for last-sector partition table probing, like some 
kind of CAPACITY_DUBIOUS flag, causing it to be skipped on these 
devices, at least by default. After all, it would seem quite unusual to 
see anything other than a DOS-style partition table on a USB storage 
device (or else no partition table at all).


  parent reply	other threads:[~2008-12-23  4:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-18 22:14 Checking a USB drive's capacity Alan Stern
2008-12-18 22:44 ` Alan Cox
2008-12-19  4:33   ` Alan Stern
2008-12-21 14:45     ` Alan Cox
2008-12-23  4:51 ` Robert Hancock [this message]
2008-12-23 12:32   ` Oliver Neukum

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=49506E5B.5090604@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.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.