linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: jeff@garzik.org, linux-ide@vger.kernel.org,
	James.Bottomley@HansenPartnership.com, bharrosh@panasas.com,
	greg.freemyer@gmail.com, linux-scsi@vger.kernel.org,
	brking@linux.vnet.ibm.com
Subject: [PATCHSET 2.6.26-rc8] block: implement extended devt
Date: Thu,  3 Jul 2008 17:33:00 +0900	[thread overview]
Message-ID: <1215073986-4709-1-git-send-email-tj@kernel.org> (raw)

Hello, all.

This patchset implements extended devt for block devices.  This is
mainly to work around sd limitations (16 minors per device) but can
easily be used to allow more partitions or more devices.

With it turned on, a libata disk w/ 60 partitions looks like the
following.

  # cat /proc/partitions 
  major   minor   #blocks  name

     3        0   78184008 hda
     3        1   26218048 hda1
     3        2    1052257 hda2
     8        0  156290904 sda
     8        1       8001 sda1
     8        2       8032 sda2
     8        3       8032 sda3
     8        4          1 sda4
   ...
     8       15       8001 sda15
   259        0       8001 sda16
   259        1       8001 sda17
   259        2       8001 sda18
   ...
   259       43       8001 sda59
   259       44       8001 sda60

As you can see, partitions over the genhd->minors limit gets assigned
under major 259 which breaks the predetermined contiguous minors
assumption.  I've tested a number of things on it and everything seems
to work just fine including mounting as root.

A debug option CONFIG_DEBUG_BLOCK_EXT_DEVT is also implemented, when
enabled, the /proc/partitions looks like the following.

  # cat /proc/partitions
  major   minor   #blocks  name

     3        0   78184008 hda
   259        0   26218048 hda1
   259   524288    1052257 hda2
     8        0  156290904 sda
   259   262144       8001 sda1
   259   786432       8032 sda2
   259   131072       8032 sda3
   259   655360          1 sda4
   259   393216       8001 sda5
   259   917504       8001 sda6
   259    65536       8001 sda7
   ...
   259   114688       8001 sda55
   259   638976       8001 sda56
   259   376832       8001 sda57
   259   901120       8001 sda58
   259   245760       8001 sda59
   259   770048       8001 sda60

The option forces all partitions to be allocated from the extended
region and spreads the minors as apart as possible to achieve two
goals.

* Detect kernel or userland code which assumes pre-determined
  consecutive block devts.

* Prevent such code from accessing the wrong partition and corrupting
  it by making devts far apart from each other.

I thought about making the spread allocation default for the extended
area while keeping the conventional minors as they are but that seemed
like an overkill.  Especially because the only interface which reveals
how many consecutive minors are allocated is sysfs attribute "range"
which doesn't change after this patchset.  A new attribute "ext_range"
which indicates the total limit of minors includnig the extended ones
is added instead.

I chose major 259 at my own whim.  Is it okay to use this value?  As
extended devts don't care what MAJ:MIN is used, we can also create a
pool of MAJ:MINs which any driver can allocate MAJ:MIN from.
Switching to such mechanism shouldn't be too difficult (some kobj_map
adjustments will be necessary tho) so no need to worry about it now.

This patchset is also available in the following git tree.

  http://git.kernel.org/?p=linux/kernel/git/tj/misc.git;a=shortlog;h=block-extended-devt
  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-extended-devt

Thanks.

 block/genhd.c          |  268 ++++++++++++++++++++++++++++++++++++++++---------
 block/ioctl.c          |    6 -
 drivers/ide/ide-disk.c |   17 ++-
 drivers/scsi/sd.c      |   15 ++
 fs/block_dev.c         |    2 
 fs/partitions/check.c  |   44 ++++++--
 include/linux/fs.h     |    1 
 include/linux/genhd.h  |   36 ++++++
 include/linux/major.h  |    2 
 lib/Kconfig.debug      |   16 ++
 10 files changed, 340 insertions(+), 67 deletions(-)

 --
 tejun

             reply	other threads:[~2008-07-03 13:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  8:33 Tejun Heo [this message]
2008-07-03  8:33 ` [PATCH 1/6] block: misc updates Tejun Heo
2008-07-03  8:33 ` [PATCH 2/6] block: don't depend on consecutive minor space Tejun Heo
2008-07-03  8:33 ` [PATCH 3/6] block: implement extended minors Tejun Heo
2008-07-03  8:33 ` [PATCH 4/6] block: adjust formatting for large minors and add ext_range sysfs attr Tejun Heo
2008-07-03  8:33 ` [PATCH 5/6] sd/ide-disk: apply extended minors to sd and ide Tejun Heo
2008-07-03  8:33 ` [PATCH 6/6] block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT Tejun Heo
2008-07-03 13:28 ` [PATCHSET 2.6.26-rc8] block: implement extended devt Matthew Wilcox
2008-07-03 15:54   ` Tejun Heo
2008-07-06 14:37 ` Tejun Heo

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=1215073986-4709-1-git-send-email-tj@kernel.org \
    --to=tj@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=greg.freemyer@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --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).