[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0812181641540.2217-100000@iolanthe.rowland.org>
Date: Thu, 18 Dec 2008 17:14:44 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Jens Axboe <axboe@...nel.dk>
cc: Kernel development list <linux-kernel@...r.kernel.org>
Subject: Checking a USB drive's capacity
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 would make more sense to carry out this test after the first sector
has been read. That's done by the partition management code in the
gendisk layer. Would near the end of check_partition() be an
appropriate place to make the test? And could I essentially copy the
code in scsi_ioctl.c:__blk_send_generic()?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists