From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Grant Grundler <grundler@google.com>
Cc: Clemens Fruhwirth <clemens@endorphin.org>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] Forcing capacity sizes for block devices
Date: Mon, 21 Dec 2009 22:59:34 +0100 [thread overview]
Message-ID: <200912212259.34808.bzolnier@gmail.com> (raw)
In-Reply-To: <da824cf30912211204jc70fc10ta6f6de1208d2b364@mail.gmail.com>
On Monday 21 December 2009 09:04:03 pm Grant Grundler wrote:
> On Sun, Dec 20, 2009 at 9:43 AM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> > On Sunday 20 December 2009 01:05:35 pm Clemens Fruhwirth wrote:
> >> Make the size attribute of block devices writable via sysfs. This
> >> allows userspace to force
> >> device boundaries in cases where the device driver is unable to detect
> >> the correct size, as
> >> with spec-incompliant SD card readers. Also see
> >> http://marc.info/?t=125555550200010&r=1&w=2
> >
> > Just a wild idea but maybe the current block infrastructure for handling
> > ATA HPA (see commit db429e9 and e957b60 one) can be used to automatically
> > detect and workaround the issue?
>
> Are you referring to this change?
> + libata.ignore_hpa= [LIBATA] Ignore HPA limit
> + libata.ignore_hpa=0 keep BIOS limits (default)
> + libata.ignore_hpa=1 ignore limits, using full disk
Nah.
> My git-foo isn't very good...what command will display the two changes
> you refer to above?
git log -p --color db429e9^1..e957b60
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.
New/empty cards would still need to be 'force partitioned' first using
fdisk (or sfdisk if fdisk doesn't allow such operation) but after it's
done the partition rescan on fdisk's exit will recognize new device's
capacity automatically..
> about b0rked HW, the user (or udev maybe?) can workaround this issue.
> Given how simple the patch, I don't see any reason to reject it.
Simple to write or simple to maintain? ;)
To be honest the patch looks like a gross and dangerous hack..
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).
--
Bartlomiej Zolnierkiewicz
next prev parent reply other threads:[~2009-12-21 22:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-20 12:05 [PATCH] Forcing capacity sizes for block devices Clemens Fruhwirth
2009-12-20 13:19 ` [PATCH] Forcing capacity sizes for block devices - (sorry, gmail ruined inlining with wordwrapping in the last mail) Clemens Fruhwirth
2009-12-20 17:43 ` [PATCH] Forcing capacity sizes for block devices Bartlomiej Zolnierkiewicz
2009-12-21 20:04 ` Grant Grundler
2009-12-21 21:59 ` Bartlomiej Zolnierkiewicz [this message]
2009-12-22 20:15 ` Grant Grundler
[not found] ` <2f83750a0912240503g3aa7bcbw876a164d0e350b27@mail.gmail.com>
2009-12-24 13:40 ` Clemens Fruhwirth
2010-01-25 14:49 ` Clemens Fruhwirth
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=200912212259.34808.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=clemens@endorphin.org \
--cc=grundler@google.com \
--cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).