public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Witkowski <skylynx@wp.pl>
To: "Paul B. Henson" <henson@acm.org>
Cc: linux-bcache@vger.kernel.org
Subject: Re: register_bcache() error opening /dev/md2: bad block/bucket size
Date: Mon, 16 Dec 2013 01:39:45 +0100	[thread overview]
Message-ID: <52AE4BD1.3080001@wp.pl> (raw)
In-Reply-To: <000401ceefb5$f0aa6160$d1ff2420$@acm.org>

On 12/03/2013 12:26 AM, Paul B. Henson wrote:
> Haven't seen much traffic on the list, maybe everybody is still recovering
> from turkey comas (at least in the US ;) ).
>
> No thoughts on this issue? Am I misunderstanding the purpose of the -w
> argument, is it not intended to align with the SSD page size?

After deep digging in this area I would say that the problem is 
somewhere else. All internal stuff of Linux kernel has default memory 
page size of 4kB. That's way You can't use ext4 filesystem with 8kB 
block size on x86 which is related to memory page size (4kB). Linus in 
the mailing list said that using larger pages will be huge waste of 
memory so that way the didn't do it for now. Anyway I think that with 
this approach that is implemented in bcache it's not possible to use 
different size of block size larger than 4kB (smaller is not the issue). 
Maybe using different soft there is different approach so it is possible 
to use larger block but bcache I think I use this. The another problem 
is that SSD's manufacturers don't release information about some basic 
info about SSD like page size or nand erase block size (I spent long 
hours to get some information from forums but is not official info from 
manufacturers). So that way it's hard to say if SSD disk will wait for 
another 4kB of page and create 2x4kB = 8kB and write "full" page and how 
it will hit performance during reads and writes. Some controllers use 
compression during write so it's hard to get any info how is works.
Now I'm trying to get some info from SSD manufacturer of my SSD's disks 
(I also have disks that have 8kB page size) how disk will work with 
smaller size of page.

regards
Jakub Witkowski

>
>> -----Original Message-----
>> From: Paul Henson [mailto:paul.b.henson@gmail.com] On Behalf Of Paul B.
>> Henson
>> Sent: Friday, November 29, 2013 7:38 PM
>> To: linux-bcache@vger.kernel.org
>> Subject: register_bcache() error opening /dev/md2: bad block/bucket size
>>
>> I'm trying to set up a mirror of two Samsung 840 Pro 256GB SSDs as a
>> cache device. Per their specs, the page size is 8k, and the erase block
>> size is 1024k, so I created the cache device as:
>>
>> make-bcache --wipe-bcache -b 1024k -w 8k -C /dev/md2
>>
>> With a bucket size equal to the erase block, and a block size equal to
>> the page size. The documentation on block size wasn't really clear, but
>> I believe it's supposed to equal the ssd page size, ie, the minimum io
>> size for the device.
>>
>> However, when trying to register this cache device, it fails with:
>>
>> bcache: register_bcache() error opening /dev/md2: Bad block/bucket size
>>
>> Looking at the code:
>>
>>                  err = "Bad block/bucket size";
>>                  if (!is_power_of_2(sb->block_size) ||
>>                      sb->block_size > PAGE_SECTORS ||
>>                      !is_power_of_2(sb->bucket_size) ||
>>                      sb->bucket_size < PAGE_SECTORS)
>>                          goto err;
>>
>> and given PAGE_SIZE = 4096 and PAGE_SECTORS = 8, it's complaining that my
>> cache device block size of 8k is greater than the page size of 4k. I guess
>> I could create my cache device with a block size of 4k to make it work,
> but
>> that seems inefficient as it does not match the page size. What's this
>> limitation about? Can it be changed? Are SSD's with a > 4k page size just
>> poor choices for a cache device?
>>
>> Thanks...
>
>

  reply	other threads:[~2013-12-16  0:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-30  3:37 register_bcache() error opening /dev/md2: bad block/bucket size Paul B. Henson
2013-12-02 23:26 ` Paul B. Henson
2013-12-16  0:39   ` Jakub Witkowski [this message]
2013-12-16  1:02     ` Matthew Patton

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=52AE4BD1.3080001@wp.pl \
    --to=skylynx@wp.pl \
    --cc=henson@acm.org \
    --cc=linux-bcache@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