Re: [PATCH] Forcing capacity sizes for block devices

[Clemens Fruhwirth <clemens@endorphin.org>]

Hi Bartlomiej, Hi Grant!

(sorry for resending this mail, gmail switched into HTML mode for
unknown reasons, and vger.kernel.org rightfully rejected this mail)

On Mon, Dec 21, 2009 at 10:59 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>
> We should be able to detect working SD reader/card combination in sd
> driver's ->set_capacity method implementation (i.e. by issuing read
> request for the last partitioned sector outside of the reported device
> capacity) during the initial partition table scan and at the same time
> adjust the device capacity used by the kernel if necessary.

1. I disagree with the strategy to add some automatism that does not
work for all cases (unformated cards in this case). Do you want the
user to jump through the additional hop of creating oversized
partition tables that fdisk and friends might not even allow easily?
The case with manual override is easier and more straight forward.
Also this approach is tied to using partition tables and in my case SD
cards work fine without partition tables.

2. I strongly opt for not-creating a kernel that tries to domineer[1]
over its users. If I say my device is size X I want the kernel to
follow that order. Also I dislike the kernel to probe beyond the
device boundaries unless I told it do so. I don't want to be this
behavior to be auto enabled by (probably broken) partition tables that
I can not even see before plugging that disk into my device (and
naturally triggering this behavior)

3. The kernel is not supposed to work correctly when writing incorrect
junk to random sysfs files. So assuming the required knowledge for
manual intervention is ok at /sys.

> Firstly block layer needs to be properly informed about capacity changes
> (set_capacity() + request for partition rescan which the patch doesn't do)
> and secondly fixing the problem at the sysfs block/partition layer seems
> to be a layering violation (i.e. it also allows partition size changes).

git log -p --color db429e9^1..e957b60 does not seem related to me. The
implementation of ide_disk_set_capacity suggests that the semantic of
set_capacity is that the caller can make the device smaller than
probed_capacity with the intention to protect stuff (Host Protect
Area?). The caller can not enlarge the device beyond the device
boundaries because of its first line "u64 set = min(capacity,
drive->probed_capacity)". The intention of my patch and its potential
use of any set_capacity is exactly that, namely to override these
device limits. So it's seems a bit orthogonal.

I don't object to inform the device layer somehow about the forceful
size change, however is set_capacity really the intended place to do
it? Where do we set nr_sects, if so?

[1] Sorry if that translation sounds strange:
http://dict.leo.org/ende?search=bevormunden
--
Fruhwirth Clemens http://clemens.endorphin.org