Partitions on bcache devices

Partitions on bcache devices

[Wido den Hollander]

Hi,

Currently it is not possible to create partitions on bcache devices, eg, if you have bcache0 you can't create bcache0p1, bcache0p2, etc.

There are patches [0] out there which 'enable' this, but they aren't suited to be send upstream.

For the Ceph [1] project it would be very beneficial if bcache would support the creation of partitions on the devices.

I'm not a kernel nor bcache developer, so I don't know what has to be done exactly, but I'm trying to see if this can be implemented in this year.

Is work for this underway? If yes, what is the status? If not, what has to be done and how can I assist / support it?

Thanks!

Wido

[0]: https://yaple.net/2016/03/31/bcache-partitions-and-dkms/
[1]: http://ceph.com/

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Le Wed, 28 Sep 2016 15:45:07 +0200 (CEST)
Wido den Hollander <wido@42on.com> écrivait:

> Hi,
> 
> Currently it is not possible to create partitions on bcache devices,
> eg, if you have bcache0 you can't create bcache0p1, bcache0p2, etc.
> 
> There are patches [0] out there which 'enable' this, but they aren't
> suited to be send upstream.
> 
> For the Ceph [1] project it would be very beneficial if bcache would
> support the creation of partitions on the devices.

What's the use case exactly? You can create LVM lvs on bcache devices
if you need to split them. And I don't really understand why it would
be beneficial to Ceph, which is about agreggating many devices.

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Partitions on bcache devices

[Wido den Hollander]

> Op 28 september 2016 om 19:11 schreef Emmanuel Florac <eflorac@intellique.com>:
> 
> 
> Le Wed, 28 Sep 2016 15:45:07 +0200 (CEST)
> Wido den Hollander <wido@42on.com> écrivait:
> 
> > Hi,
> > 
> > Currently it is not possible to create partitions on bcache devices,
> > eg, if you have bcache0 you can't create bcache0p1, bcache0p2, etc.
> > 
> > There are patches [0] out there which 'enable' this, but they aren't
> > suited to be send upstream.
> > 
> > For the Ceph [1] project it would be very beneficial if bcache would
> > support the creation of partitions on the devices.
> 
> What's the use case exactly? You can create LVM lvs on bcache devices
> if you need to split them. And I don't really understand why it would
> be beneficial to Ceph, which is about agreggating many devices.
> 

Underneath a Ceph OSD you currently have the FileStore. This uses two partitions on a disk. One for a Journal and the rest for XFS to store it's data.

$ ceph-disk prepare /dev/sda

That would create a GPT layout:

- sda1: 5GB Journal
- sda2: X TB XFS data

Now, with the upcoming BlueStore for Ceph you would have this layout:

- sda1: XFS/EXT4 OSD metadata
- sda2: RocksDB
- sda3: RocksDB WAL
- sda4: BlueStore Blob/Data

In both cases Ceph wants to create partitions on all disks it uses. By adding bcache in between the performance can be boosted really well. Fast NVM-e SSDs with some large SATA drives vastly improve performance.

Yes, you could use LVM in between, but that just adds more layers and is rather complex to accomplish with the current tooling. If bcache would support partitions it would all be a lot easier.

And next to Ceph there might be other tools which can benefit from partitions on bcache, who knows?

Wido

> -- 
> ------------------------------------------------------------------------
> Emmanuel Florac     |   Direction technique
>                     |   Intellique
>                     |	<eflorac@intellique.com>
>                     |   +33 1 78 94 84 02
> ------------------------------------------------------------------------

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Le Wed, 28 Sep 2016 21:14:50 +0200 (CEST)
Wido den Hollander <wido@42on.com> écrivait:

> In both cases Ceph wants to create partitions on all disks it uses.
> By adding bcache in between the performance can be boosted really
> well. Fast NVM-e SSDs with some large SATA drives vastly improve
> performance.
> 
> Yes, you could use LVM in between, but that just adds more layers and
> is rather complex to accomplish with the current tooling. If bcache
> would support partitions it would all be a lot easier.
> 
> And next to Ceph there might be other tools which can benefit from
> partitions on bcache, who knows?

Two points: first I'm pretty sure LVM is the preferred method nowadays
to create volumes on disks that are not boot drives. In fact, all
enterprises distros propose to set up even the boot drive with LVM
instead of partitionning and have been doing so for 10 years. 
So I'm pretty sure having in ceph the option to use LVM instead of
partitionning would be a darn good thing :)

Second: are you absolutely sure you can't partition a bcache device?
Does parted refuse to open and partition it? In which case, you may
only be missing some appropriate udev rules.

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Partitions on bcache devices

[Wido den Hollander]

> Op 29 september 2016 om 16:09 schreef Emmanuel Florac <eflorac@intellique.com>:
> 
> 
> Le Wed, 28 Sep 2016 21:14:50 +0200 (CEST)
> Wido den Hollander <wido@42on.com> écrivait:
> 
> > In both cases Ceph wants to create partitions on all disks it uses.
> > By adding bcache in between the performance can be boosted really
> > well. Fast NVM-e SSDs with some large SATA drives vastly improve
> > performance.
> > 
> > Yes, you could use LVM in between, but that just adds more layers and
> > is rather complex to accomplish with the current tooling. If bcache
> > would support partitions it would all be a lot easier.
> > 
> > And next to Ceph there might be other tools which can benefit from
> > partitions on bcache, who knows?
> 
> Two points: first I'm pretty sure LVM is the preferred method nowadays
> to create volumes on disks that are not boot drives. In fact, all
> enterprises distros propose to set up even the boot drive with LVM
> instead of partitionning and have been doing so for 10 years. 
> So I'm pretty sure having in ceph the option to use LVM instead of
> partitionning would be a darn good thing :)
> 

Thanks for the information :) Currently not really a option with Ceph.

> Second: are you absolutely sure you can't partition a bcache device?
> Does parted refuse to open and partition it? In which case, you may
> only be missing some appropriate udev rules.
> 

Yes, I'm sure. You can create the partitions, but they will not show up as devices which you can use due to a limitation in the bcache kernel driver.

Patches [0] are out there to make this work, but they are not in bcache yet.

Hence my thread if this support can be added.

Wido

[0]: https://yaple.net/2016/03/31/bcache-partitions-and-dkms/

> -- 
> ------------------------------------------------------------------------
> Emmanuel Florac     |   Direction technique
>                     |   Intellique
>                     |	<eflorac@intellique.com>
>                     |   +33 1 78 94 84 02
> ------------------------------------------------------------------------

Re: Partitions on bcache devices

[Jens-U. Mozdzen]

Hi Emmanuel,

Zitat von Emmanuel Florac <eflorac@intellique.com>:
> [...]
> Two points: first I'm pretty sure LVM is the preferred method nowadays
> to create volumes on disks that are not boot drives. In fact, all
> enterprises distros propose to set up even the boot drive with LVM
> instead of partitionning and have been doing so for 10 years.
> So I'm pretty sure having in ceph the option to use LVM instead of
> partitionning would be a darn good thing :)

I disagree. As a matter of fact, it'd be a bad idea IMO: Unlike with  
what you have given as good examples for LVM usage, the disk layout on  
OSDs is fixed. So you're throwing in a (rather fast, but unnecessary)  
code path intended to provide flexibility, where you need none. This  
causes delays and provides potential problems that can be avoided.  
Another counter-example: You wouldn't put LVM on a disk that's  
intended as a (100%) MD-RAID volume, and add an LV as RAID member...  
you'll add a partition table for a reason, but no extra layer between  
the partition and the RAID stuff.

> Second: are you absolutely sure you can't partition a bcache device?

While I haven't tried in a while, that's the way it was when I tested  
last. No partitioning of the bcache device. If you want multiple  
bcached partitions on a backing store, partition first and then create  
multiple bcached devices. This could be done with the BlueStore  
installer as well, but somebody will have to provide the code to  
optionally bcache the partitions.

Regards,
J

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

Le Thu, 29 Sep 2016 17:38:38 +0200 (CEST)
Wido den Hollander <wido@42on.com> écrivait:

> Yes, I'm sure. You can create the partitions, but they will not show
> up as devices which you can use due to a limitation in the bcache
> kernel driver.
> 
> Patches [0] are out there to make this work, but they are not in
> bcache yet.
> 
> Hence my thread if this support can be added.
> 
> Wido
> 
> [0]: https://yaple.net/2016/03/31/bcache-partitions-and-dkms/

Ah OK, it's because bcache driver only allocates one minor number to
the device... Could be done indeed.

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Le Thu, 29 Sep 2016 17:40:56 +0200
"Jens-U. Mozdzen" <jmozdzen@nde.ag> écrivait:

> Another counter-example: You wouldn't put LVM on a disk that's  
> intended as a (100%) MD-RAID volume, and add an LV as RAID member...  
> you'll add a partition table for a reason, but no extra layer
> between the partition and the RAID stuff.
> 

I agree, but usually you wouldn't partition an MD-RAID either, would
you? OSDs are still holding (so far) ordinary filesystems locally
mounted on the nodes (except for BlueStore AFAIK).

Anyway bcache would mostly make sense for the journal, much less for
the data section, so wouldn't it better to use bcache (or flash) for
journal/metadata only?

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Partitions on bcache devices

[Wido den Hollander]

> Op 29 september 2016 om 18:31 schreef Emmanuel Florac <eflorac@intellique.com>:
> 
> 
> Le Thu, 29 Sep 2016 17:40:56 +0200
> "Jens-U. Mozdzen" <jmozdzen@nde.ag> écrivait:
> 
> > Another counter-example: You wouldn't put LVM on a disk that's  
> > intended as a (100%) MD-RAID volume, and add an LV as RAID member...  
> > you'll add a partition table for a reason, but no extra layer
> > between the partition and the RAID stuff.
> > 
> 
> I agree, but usually you wouldn't partition an MD-RAID either, would
> you? OSDs are still holding (so far) ordinary filesystems locally
> mounted on the nodes (except for BlueStore AFAIK).
> 

I have partitioned MD-RAID before, works just fine.

FileStore currently has a local XFS filesystem indeed, with BlueStore the OSD will consume a RAW device.

> Anyway bcache would mostly make sense for the journal, much less for
> the data section, so wouldn't it better to use bcache (or flash) for
> journal/metadata only?
>

The Journal will be gone with BlueStore and that will become the RocksDB WAL. Using bcache for the data partition (the large one) will still benefit since frequently accessed blocks can be cached and thus lower the read latency.

The question still remains, can bcache be patched that it allocates the right minor in the kernel so that it allows for partitions.

I'm not a kernel nor bcache developer, just looking for somebody who would be willing to do this. Happy to assist, support and test!

Wido
 
> -- 
> ------------------------------------------------------------------------
> Emmanuel Florac     |   Direction technique
>                     |   Intellique
>                     |	<eflorac@intellique.com>
>                     |   +33 1 78 94 84 02
> ------------------------------------------------------------------------

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Le Thu, 29 Sep 2016 18:52:14 +0200 (CEST)
Wido den Hollander <wido@42on.com> écrivait:

> > I agree, but usually you wouldn't partition an MD-RAID either, would
> > you? OSDs are still holding (so far) ordinary filesystems locally
> > mounted on the nodes (except for BlueStore AFAIK).
> >   
> 
> I have partitioned MD-RAID before, works just fine.
> 

Yes, sure. It just doesn't feel right, my  grey-bearded Unix instinct
tingles :)

> The question still remains, can bcache be patched that it allocates
> the right minor in the kernel so that it allows for partitions.

Even looks easy... As Sam Yaple made a patch.

> I'm not a kernel nor bcache developer, just looking for somebody who
> would be willing to do this. Happy to assist, support and test!

Well if I have some time I may give it a try next week :)

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Partitions on bcache devices

[Jens-U. Mozdzen]

Zitat von Emmanuel Florac <eflorac@intellique.com>:
> Le Thu, 29 Sep 2016 17:40:56 +0200
> "Jens-U. Mozdzen" <jmozdzen@nde.ag> écrivait:
>
>> Another counter-example: You wouldn't put LVM on a disk that's
>> intended as a (100%) MD-RAID volume, and add an LV as RAID member...
>> you'll add a partition table for a reason, but no extra layer
>> between the partition and the RAID stuff.
>>
>
> I agree, but usually you wouldn't partition an MD-RAID either, would
> you? OSDs are still holding (so far) ordinary filesystems locally
> mounted on the nodes (except for BlueStore AFAIK).

in both cases, it's a matter of your point of view.

I treat bcache as a means to introduce "hybrid disks" (or rather  
hybrid block devices), where I can take standard HDDs and extend them  
by adding SSD caching at the OS layer - instead of buying special RAID  
controllers or hybrid disks. This adds a layer of flexibility (in  
terms of "buying choice") for me.

>
> Anyway bcache would mostly make sense for the journal, much less for
> the data section, so wouldn't it better to use bcache (or flash) for
> journal/metadata only?

SSDs provide a lot of space nowadays, why not speed up all accesses?  
This will lead to faster persistence and probably faster read access  
as well (depending on your workload).

Re: Partitions on bcache devices

[Wido den Hollander]

> Op 29 september 2016 om 19:11 schreef Emmanuel Florac <eflorac@intellique.com>:
> 
> 
> Le Thu, 29 Sep 2016 18:52:14 +0200 (CEST)
> Wido den Hollander <wido@42on.com> écrivait:
> 
> > > I agree, but usually you wouldn't partition an MD-RAID either, would
> > > you? OSDs are still holding (so far) ordinary filesystems locally
> > > mounted on the nodes (except for BlueStore AFAIK).
> > >   
> > 
> > I have partitioned MD-RAID before, works just fine.
> > 
> 
> Yes, sure. It just doesn't feel right, my  grey-bearded Unix instinct
> tingles :)
> 
> > The question still remains, can bcache be patched that it allocates
> > the right minor in the kernel so that it allows for partitions.
> 
> Even looks easy... As Sam Yaple made a patch.
> 
> > I'm not a kernel nor bcache developer, just looking for somebody who
> > would be willing to do this. Happy to assist, support and test!
> 
> Well if I have some time I may give it a try next week :)
> 

I was wondering if you were able to take a look at this?

Wido

> -- 
> ------------------------------------------------------------------------
> Emmanuel Florac     |   Direction technique
>                     |   Intellique
>                     |	<eflorac@intellique.com>
>                     |   +33 1 78 94 84 02
> ------------------------------------------------------------------------

Re: Partitions on bcache devices

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

Le Fri, 14 Oct 2016 14:15:35 +0200 (CEST)
Wido den Hollander <wido@42on.com> écrivait:

> > > I'm not a kernel nor bcache developer, just looking for somebody
> > > who would be willing to do this. Happy to assist, support and
> > > test!  
> > 
> > Well if I have some time I may give it a try next week :)
> >   
> 
> I was wondering if you were able to take a look at this?

Sorry not yet, I hadn't much time these past few days.

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[PATCH v1] bcache: partition support: add 16 minors per major

[Eric Wheeler]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2280 bytes --]

On Fri, 14 Oct 2016, Wido den Hollander wrote:
> > Op 29 september 2016 om 19:11 schreef Emmanuel Florac <eflorac@intellique.com>:
> > Le Thu, 29 Sep 2016 18:52:14 +0200 (CEST)
> > Wido den Hollander <wido@42on.com> écrivait:
> > > > I agree, but usually you wouldn't partition an MD-RAID either, would
> > > > you? OSDs are still holding (so far) ordinary filesystems locally
> > > > mounted on the nodes (except for BlueStore AFAIK).
> > > I have partitioned MD-RAID before, works just fine.
> > 
> > Yes, sure. It just doesn't feel right, my  grey-bearded Unix instinct
> > tingles :)
> > 
> > > The question still remains, can bcache be patched that it allocates
> > > the right minor in the kernel so that it allows for partitions.
> > 
> > Even looks easy... As Sam Yaple made a patch.
> > 
> > > I'm not a kernel nor bcache developer, just looking for somebody who
> > > would be willing to do this. Happy to assist, support and test!
> > 
> > Well if I have some time I may give it a try next week :)
> > 
> 
> I was wondering if you were able to take a look at this?

Hi Wido,

See below and please test.  It works for me, but I've not done any more 
than create a partition and verify that it was detected.  Use-case 
opinions aside, some may or may not wish to use partitions atop of bcache. 
(If you do, just make sure they are aligned correctly!).

I'll add your tested-by and request a pull for v4.9 unless someone has 
good reason to implement this differently.

Kent, is there any reason to change this implementation?

--
Eric Wheeler



diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 849ad44..6e53afd 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -58,6 +58,7 @@
 struct workqueue_struct *bcache_wq;
 
 #define BTREE_MAX_PAGES		(256 * 1024 / PAGE_SIZE)
+#define BCACHE_MINORS		16 /* partition support */
 
 /* Superblock */
 
@@ -783,8 +784,10 @@ static int bcache_device_init(struct bcache_device *d, unsigned block_size,
 	if (minor < 0)
 		return minor;
 
+	minor *= BCACHE_MINORS;
+
 	if (!(d->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
-	    !(d->disk = alloc_disk(1))) {
+	    !(d->disk = alloc_disk(BCACHE_MINORS))) {
 		ida_simple_remove(&bcache_minor, minor);
 		return -ENOMEM;
 	}

Re: [PATCH v1] bcache: partition support: add 16 minors per bcacheN device

[Eric Wheeler]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2551 bytes --]


[ Fixed subject: 
  Really I meant 16 minors per device, not per-major; major hasn't changed.]

On Sun, 23 Oct 2016, Eric Wheeler wrote:

> On Fri, 14 Oct 2016, Wido den Hollander wrote:
> > > Op 29 september 2016 om 19:11 schreef Emmanuel Florac <eflorac@intellique.com>:
> > > Le Thu, 29 Sep 2016 18:52:14 +0200 (CEST)
> > > Wido den Hollander <wido@42on.com> écrivait:
> > > > > I agree, but usually you wouldn't partition an MD-RAID either, would
> > > > > you? OSDs are still holding (so far) ordinary filesystems locally
> > > > > mounted on the nodes (except for BlueStore AFAIK).
> > > > I have partitioned MD-RAID before, works just fine.
> > > 
> > > Yes, sure. It just doesn't feel right, my  grey-bearded Unix instinct
> > > tingles :)
> > > 
> > > > The question still remains, can bcache be patched that it allocates
> > > > the right minor in the kernel so that it allows for partitions.
> > > 
> > > Even looks easy... As Sam Yaple made a patch.
> > > 
> > > > I'm not a kernel nor bcache developer, just looking for somebody who
> > > > would be willing to do this. Happy to assist, support and test!
> > > 
> > > Well if I have some time I may give it a try next week :)
> > > 
> > 
> > I was wondering if you were able to take a look at this?
> 
> Hi Wido,
> 
> See below and please test.  It works for me, but I've not done any more 
> than create a partition and verify that it was detected.  Use-case 
> opinions aside, some may or may not wish to use partitions atop of bcache. 
> (If you do, just make sure they are aligned correctly!).
> 
> I'll add your tested-by and request a pull for v4.9 unless someone has 
> good reason to implement this differently.
> 
> Kent, is there any reason to change this implementation?
> 
> --
> Eric Wheeler
> 
> 
> 
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index 849ad44..6e53afd 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -58,6 +58,7 @@
>  struct workqueue_struct *bcache_wq;
>  
>  #define BTREE_MAX_PAGES		(256 * 1024 / PAGE_SIZE)
> +#define BCACHE_MINORS		16 /* partition support */
>  
>  /* Superblock */
>  
> @@ -783,8 +784,10 @@ static int bcache_device_init(struct bcache_device *d, unsigned block_size,
>  	if (minor < 0)
>  		return minor;
>  
> +	minor *= BCACHE_MINORS;
> +
>  	if (!(d->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
> -	    !(d->disk = alloc_disk(1))) {
> +	    !(d->disk = alloc_disk(BCACHE_MINORS))) {
>  		ida_simple_remove(&bcache_minor, minor);
>  		return -ENOMEM;
>  	}

Re: [PATCH v1] bcache: partition support: add 16 minors per major

[Wido den Hollander]

> Op 24 oktober 2016 om 3:19 schreef Eric Wheeler <bcache@lists.ewheeler.net>:
> 
> 
> On Fri, 14 Oct 2016, Wido den Hollander wrote:
> > > Op 29 september 2016 om 19:11 schreef Emmanuel Florac <eflorac@intellique.com>:
> > > Le Thu, 29 Sep 2016 18:52:14 +0200 (CEST)
> > > Wido den Hollander <wido@42on.com> écrivait:
> > > > > I agree, but usually you wouldn't partition an MD-RAID either, would
> > > > > you? OSDs are still holding (so far) ordinary filesystems locally
> > > > > mounted on the nodes (except for BlueStore AFAIK).
> > > > I have partitioned MD-RAID before, works just fine.
> > > 
> > > Yes, sure. It just doesn't feel right, my  grey-bearded Unix instinct
> > > tingles :)
> > > 
> > > > The question still remains, can bcache be patched that it allocates
> > > > the right minor in the kernel so that it allows for partitions.
> > > 
> > > Even looks easy... As Sam Yaple made a patch.
> > > 
> > > > I'm not a kernel nor bcache developer, just looking for somebody who
> > > > would be willing to do this. Happy to assist, support and test!
> > > 
> > > Well if I have some time I may give it a try next week :)
> > > 
> > 
> > I was wondering if you were able to take a look at this?
> 
> Hi Wido,
> 
> See below and please test.  It works for me, but I've not done any more 
> than create a partition and verify that it was detected.  Use-case 
> opinions aside, some may or may not wish to use partitions atop of bcache. 
> (If you do, just make sure they are aligned correctly!).
> 
> I'll add your tested-by and request a pull for v4.9 unless someone has 
> good reason to implement this differently.
> 

I build a kernel yesterday and tested it this morning, what I see is that it works and I can use the devices.

root@VM-f3149531-0c9f-47c4-bbf6-85226190bd26:~# ls -l /dev/bcache0*
brw-rw---- 1 root disk 251, 0 Oct 25 08:57 /dev/bcache0
brw-rw---- 1 root disk 251, 1 Oct 25 08:58 /dev/bcache0p1
brw-rw---- 1 root disk 251, 2 Oct 25 08:59 /dev/bcache0p2
brw-rw---- 1 root disk 251, 3 Oct 25 09:00 /dev/bcache0p3
root@VM-f3149531-0c9f-47c4-bbf6-85226190bd26:~# parted /dev/bcache0 print
Model: Unknown (unknown)
Disk /dev/bcache0: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  10.7GB  10.7GB  ext4         primary
 2      10.7GB  53.7GB  42.9GB  ext4         primary
 3      53.7GB  107GB   53.7GB  ext4         primary

root@VM-f3149531-0c9f-47c4-bbf6-85226190bd26:~# df -h|grep bcache
/dev/bcache0p2   40G   48M   38G   1% /tmp/bcache2
/dev/bcache0p1  9.8G   23M  9.2G   1% /tmp/bcache1
/dev/bcache0p3   50G   52M   47G   1% /tmp/bcache3
root@VM-f3149531-0c9f-47c4-bbf6-85226190bd26:~#

As you can see, I have a 100GB device, created a GPT label and three partitions. I formatted them with EXT4 and mounted them.

I can write files just as you would do on any other EXT4 filesystem.

Tested by: Wido den Hollander <wido@widodh.nl>

Wido

> Kent, is there any reason to change this implementation?
> 
> --
> Eric Wheeler
> 
> 
> 
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index 849ad44..6e53afd 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -58,6 +58,7 @@
>  struct workqueue_struct *bcache_wq;
>  
>  #define BTREE_MAX_PAGES		(256 * 1024 / PAGE_SIZE)
> +#define BCACHE_MINORS		16 /* partition support */
>  
>  /* Superblock */
>  
> @@ -783,8 +784,10 @@ static int bcache_device_init(struct bcache_device *d, unsigned block_size,
>  	if (minor < 0)
>  		return minor;
>  
> +	minor *= BCACHE_MINORS;
> +
>  	if (!(d->bio_split = bioset_create(4, offsetof(struct bbio, bio))) ||
> -	    !(d->disk = alloc_disk(1))) {
> +	    !(d->disk = alloc_disk(BCACHE_MINORS))) {
>  		ida_simple_remove(&bcache_minor, minor);
>  		return -ENOMEM;
>  	}