public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: size limit for backing store? block sizes? ("[sdx] Bad block number requested")
Date: Fri, 17 Feb 2017 09:05:27 +0100	[thread overview]
Message-ID: <20170217090527.2b22a3c8@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 20170214120548.Horde.jjkocB4OpTXTQseeIy0JLve@www3.nde.ag

Am Tue, 14 Feb 2017 12:05:48 +0100
schrieb "Jens-U. Mozdzen" <jmozdzen@nde.ag>:

> Hi *,
> 
> Zitat von Eric Wheeler <bcache@lists.ewheeler.net>:
> > On Wed, 8 Feb 2017, Kai Krakow wrote:
> > [...]  
> >> What I meant is "make-bcacke --block X". It defaults to X=512b. I
> >> think you may want to force it to 4k and see if your problem
> >> persists.  
> >
> > Maybe --block 4096 should be default in make-bcache?
> >
> > Kent, is there any reason this wouldn't be a good idea?  
> 
> actually, make-bcache seems not to default to 512 octets. If no  
> specific block size is specified on the command line, it determines  
> the maximum sector size of the devices involved:
> 
> --- cut here ---
> if (!block_size) {
> 		for (i = 0; i < ncache_devices; i++)
> 			block_size = max(block_size,
> 					 get_blocksize(cache_devices[i]));
> 
> 		for (i = 0; i < nbacking_devices; i++)
> 			block_size = max(block_size,
> 					 get_blocksize(backing_devices[i]));
> }
> --- cut here ---
> 
> get_blocksize() queries the logical block size as reported by the  
> device ( ioctl(fd, BLKSSZGET, &logical_block_size) ).
> 
> At least that's what I see at  
> https://github.com/g2p/bcache-tools/blob/master/make-bcache.c, said
> to be from Apr 16, 2014. And it seems to be the reason why invoking  
> "make-bcache -B ... -C ..." did create a proper setup for me, while  
> separating that to "make-bcache -B ..." and "make-bcache -C ..."  
> created a wrongly set up caching device for me (backing device has
> 4k sector size, caching device 512b).

The call to max() in this function clearly tells that both devices
(backing and cache) should use the same block size.

I still wonder why attaching different block-sized devices wasn't
denied for you. When I tried it once, it didn't work.

-- 
Regards,
Kai

Replies to list-only preferred.

  reply	other threads:[~2017-02-17  8:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 12:35 size limit for backing store? block sizes? ("[sdx] Bad block number requested") Jens-U. Mozdzen
2017-02-07 19:58 ` Kai Krakow
2017-02-07 23:28   ` Jens-U. Mozdzen
2017-02-07 23:57     ` Kai Krakow
2017-02-09 21:37       ` Eric Wheeler
2017-02-09 21:43         ` Kent Overstreet
2017-02-14 11:05         ` Jens-U. Mozdzen
2017-02-17  8:05           ` Kai Krakow [this message]
2017-02-10 10:57       ` Jens-U. Mozdzen
2017-02-10 19:28         ` Eric Wheeler
2017-02-14 10:52           ` Jens-U. Mozdzen

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=20170217090527.2b22a3c8@jupiter.sol.kaishome.de \
    --to=hurikhan77@gmail.com \
    --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