Try the latest bcache-3.2 branch On Thu, Aug 30, 2012 at 11:28 PM, moussa ba <musaba@xxxxxxxxx> 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 <koverstreet@xxxxxxxxxx> wrote: >> >> 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 -- 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
