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.
next prev parent 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