linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <openosd@gmail.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Boaz Harrosh <boaz@plexistor.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	Matthew Wilcox <willy@linux.intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 3/4] brd: Fix all partitions BUGs
Date: Thu, 07 Aug 2014 12:11:09 +0300	[thread overview]
Message-ID: <53E342AD.2070303@gmail.com> (raw)
In-Reply-To: <1407366387.2869.3.camel@rzwisler-mobl1.amr.corp.intel.com>

On 08/07/2014 02:06 AM, Ross Zwisler wrote:
> On Wed, 2014-08-06 at 14:33 +0300, Boaz Harrosh wrote:
> 
> With this patch we end up in what feels like a weird place where we're half
> using the old scheme of major/minor allocation, and half in the world of
> dynamic major/minors.  Devices have a major of 1 and minors that increment by
> 1, but partitions have a major of 259 (BLOCK_EXT_MAJOR):
> 
> 	brw-rw---- 1 root disk   1, 0 Aug  6 14:10 /dev/ram0
> 	brw-rw---- 1 root disk   1, 1 Aug  6 14:13 /dev/ram1
> 	brw-rw---- 1 root disk 259, 0 Aug  6 14:14 /dev/ram1p1
> 	brw-rw---- 1 root disk 259, 1 Aug  6 14:13 /dev/ram1p2
> 	brw-rw---- 1 root disk 259, 2 Aug  6 14:14 /dev/ram1p51
> 

This is when you use max_part = 1. If someone really cares, why
would he care, but if he cares like if he wants persistent
partition minors than he can use  max_part = 8, say and it will
all go nice. (And if he creates 9 partitions on a device then
the last one will be from the 259 dynamic range)

So you see it is all in the user choice. If he cares at all
because I do not see why it matters

> For NVMe and PRD you get a major of 259 all around:
> 
> 	brw-rw---- 1 root disk 259, 0 Aug  6 16:55 /dev/pmem0
> 	brw-rw---- 1 root disk 259, 2 Aug  6 16:55 /dev/pmem0p1
> 	brw-rw---- 1 root disk 259, 3 Aug  6 16:55 /dev/pmem0p2
> 	brw-rw---- 1 root disk 259, 1 Aug  6 16:54 /dev/pmem1
> 
> It could be that this is fine, but it just smells fishy to me I guess.
> 

If you go this way then dynamic creation with the mknod trick does not work
because there is no association in the system with your driver. Whats so fishy
I have read the all partitions code this is simple math really. This is the way
it works.

> Also, it looks like you can still create a new device with this patch, but you
> can't create partitions on that device.  Not sure if this is just what you get
> when you dynamically create a device on the fly, or if it's a symptom of
> something larger.
> 

What? I just tried again this all works fine for me, here with fdisk.
$ modprobe brd      # will create ram0-7
$ mknod /dev/ram8 b 1 8
$ fdisk /dev/ram8
  g, n, , , +2M, n, , , , , w 

I create 2 partitions 2M each and press w and it is all there.

What numbers did you use ? rd_nr, max_part, and the mknod numbers. Here it
just works fine. What did you try?

Thanks
Boaz


  reply	other threads:[~2014-08-07  9:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06 11:27 [PATCHSET 0/4] brd: partition fixes Boaz Harrosh
2014-08-06 11:29 ` [PATCH 1/4] Change direct_access calling convention Boaz Harrosh
2014-08-06 11:30 ` [PATCH 2/4] brd: Add getgeo to block ops Boaz Harrosh
2014-08-06 17:52   ` Ross Zwisler
2014-08-07  9:20     ` Boaz Harrosh
2014-08-07 14:03   ` [PATCH 2/4 v2] " Boaz Harrosh
2014-08-07 18:20     ` One Thousand Gnomes
2014-08-08  6:52       ` Boaz Harrosh
2014-08-08  6:58         ` Davidlohr Bueso
2014-08-06 11:33 ` [PATCH 3/4] brd: Fix all partitions BUGs Boaz Harrosh
2014-08-06 23:06   ` Ross Zwisler
2014-08-07  9:11     ` Boaz Harrosh [this message]
2014-08-07 18:50       ` Ross Zwisler
2014-08-07 18:53   ` Ross Zwisler
2014-08-06 11:35 ` [PATCH 4/4] brd: Request from fdisk 4k alignment Boaz Harrosh
2014-08-06 22:03   ` Ross Zwisler
2014-08-07 12:17     ` Boaz Harrosh
2014-08-07 13:00       ` Karel Zak
2014-08-07 13:51         ` Karel Zak
2014-08-07 13:57         ` Boaz Harrosh
2014-08-07 15:21           ` Karel Zak
2014-08-07 15:40             ` Boaz Harrosh

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=53E342AD.2070303@gmail.com \
    --to=openosd@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=boaz@plexistor.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=willy@linux.intel.com \
    /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).