Try the latest bcache-3.2 branch

On Thu, Aug 30, 2012 at 11:28 PM, moussa ba [off-list ref] wrote:

Ken,

I only recently got a change to try bcache-dev.  Unfortunately bcache
fails to properly set the queue_max_sectors for our device which is
128, but bcache sends down 256 entries.

I am on commit 8e8551e1060dc1286252266c6021d8d7d83c9720

Moussa

On Mon, May 14, 2012 at 6:17 PM, Kent Overstreet [off-list ref] wrote:

quoted

Thanks. Think I fixed the bug - I'd have to check, but I think what
happened is queue_max_sectors() also took into account
queue_max_sectors() in older kernels, but doesn't in newer kernels. Or
maybe just my code was always broken.

Anyways, the bcache-3.3-dev branch should work.

On Thu, May 10, 2012 at 11:38 AM, moussa ba [off-list ref] wrote:

quoted

Kent,

Apologies, we do have the queue entries available, I ran into some issues
with the driver while trying to report them:

add_random: 0
discard_granularity: 0
discard_max_bytes: 0
discard_zeroes_data: 0
hw_sector_size: 512
iostats: 0
logical_block_size: 512
max_hw_sectors_kb: 32767
max_integrity_segments: 0
max_sectors_kb: 32767
max_segments: 128
max_segment_size: 4194304
minimum_io_size: 4096
nomerges: 2
nr_requests: 255
optimal_io_size: 0
physical_block_size: 4096
read_ahead_kb: 128
rotational: 0
rq_affinity: 0
scheduler: none



On Thu, May 10, 2012 at 12:11 AM, Kent Overstreet [off-list ref]
wrote:

quoted

You mean it implements its own make_request function? It'll still have
queue limits - bcache works similarly. They might not be exported in
sysfs though...

I'll have a look at the driver.

On Thu, May 10, 2012 at 2:00 AM, moussa ba [off-list ref] wrote:

quoted

Well, that might be the problem, there is no such entry.  The driver is
basically a fake ahci driver and handles the bios directly.  It is
extremely
fast and the driver was written for very low latency IO hence the weird
driver stack.


http://lxr.linux.no/linux+v3.3.5/drivers/block/mtip32xx/mtip32xx.c#L3044.
 The mtip_make_request call fails whenever the number of entries in the
SGL

quoted

128...

Moussa

On May 9, 2012 6:02 PM, "Kent Overstreet" [off-list ref]
wrote:

quoted

That sounds like a bug in bcache - bcache should be respecting the
queue limits the underlying device exports.

Can you tell me what the various files in /sys/block/<device>/queue/
look like for your device?

On Wed, May 9, 2012 at 8:23 PM, moussa ba [off-list ref] wrote:

quoted

Tried to send this to mailing list but was rejected somehow.

---------- Forwarded message ----------
From: moussa ba <redacted>
Date: Wed, May 9, 2012 at 5:17 PM
Subject: Scatter Gather List in bio exceed driver capabilities
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org



We are using a micron PCI-E SSD as a caching device.  I am running
into
issues where the driver would fail when we try to register the cache
device.
 The failure is because bcache sends down a bio with 256 entries
while
the
device driver can only handle 128 entries.  We could make changes
inside
our
driver to chunk the requests (mind you I did not write the driver,
but
driver guys told me so...) and fix it that way.  I am assuming that
since
bcache is creating the bio to get at its metadata, it does not chunk
the
bios to fit the underlying hardware nor does it query it in some way
to
set
the bi_vcnt.

Any suggestions on how to properly address this?

Moussa

--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html