On Wed, Jun 13, 2018 at 05:58:01AM -0400, Kent Overstreet wrote: > On Mon, Jun 11, 2018 at 09:48:00PM +0200, Christoph Hellwig wrote: > > Hi all, > > > > this series cleans up various places where bcache is way too intimate > > with bio internals. This is intended as a baseline for the multi-page > > biovec work, which requires some nasty workarounds for the existing > > code. > > > > Note that I do not have a bcache test setup, so this will require > > some careful actual testing with whatever test cases are used for > > bcache. > > > > Also the new bio_reused helper should be useful at least for MD raid, > > but that work is left for later. > > Strong nak on the patch series (except for the patch to not clone in > bch_data_verify, that patch looks fine). > > Unless something has seriously changed with how multi-page bvecs work since I > started that code nothing in bcache should be broken by it - Ming, can you > confirm or deny if that's still correct? Yes, the multi-page bvecs implementation didn't have big change, and previously I run xfstests on bcache0, and no regression was observed. > > It is true that bch_bio_map() will be suboptimal when multi page bvecs go in, > but it won't be broken. The way it's used now is really conflating two different > things, but where it's used for mapping a bio to a single buffer (i.e. not > before bio_alloc_pages) that can be switched to something that just creates a > single bvec. Yes, multipage bvec shouldn't break any driver or fs. Thanks, Ming -- 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
