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 <musaba@xxxxxxxxx> wrote: > 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 <koverstreet@xxxxxxxxxx> > wrote: >> >> 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 <musaba@xxxxxxxxx> wrote: >> > 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 >> >> 128... >> > >> > Moussa >> > >> > On May 9, 2012 6:02 PM, "Kent Overstreet" <koverstreet@xxxxxxxxxx> >> > wrote: >> >> >> >> 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 <musaba@xxxxxxxxx> wrote: >> >> > Tried to send this to mailing list but was rejected somehow. >> >> > >> >> > ---------- Forwarded message ---------- >> >> > From: moussa ba <musaba@xxxxxxxxx> >> >> > Date: Wed, May 9, 2012 at 5:17 PM >> >> > Subject: Scatter Gather List in bio exceed driver capabilities >> >> > To: linux-bcache@xxxxxxxxxxxxxxx >> >> > >> >> > >> >> > >> >> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
