Re: "creative" bio usage in the RAID code

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Mon, Nov 14 2016, Christoph Hellwig wrote:

> On Mon, Nov 14, 2016 at 10:03:20AM +1100, NeilBrown wrote:
>> I would suggest adding a "bi_dev_private" field to the bio which is for
>> use by the lowest-level driver (much as bi_private is for use by the
>> top-level initiator).
>> That could be in a union with any or all of:
>> 	unsigned int		bi_phys_segments;
>> 	unsigned int		bi_seg_front_size;
>> 	unsigned int		bi_seg_back_size;
>> 
>> (any driver that needs those, would see a 'request' rather than a 'bio'
>> and so could use rq->special)
>> 
>> raid5.c could then use bi_dev_private (or bi_special, or whatever it is call).
>
> All the three above fields are those that could go away with a full
> implementation of the multipage bvec scheme.  So any field for driver
> use would still be be overhead.  If it's just for raid5 it could
> be a smaller 16 bit (or maybe even just 8 bit) one.

We currently store 2 counters in that field, and before
commit 5b99c2ffa980528a197f26 one of the fields was only 8 bits,
and that caused problems

We could possibly use __bi_remaining in place of
raid5_X_bi_active_stripes().  It wouldn't be a completely
straightforward conversion, but I think it could be made to work.

We *might* be able to use bvec_iter_advance() in place of
raid5_bi_processed_stripes().  A careful audit of the code would be
needed to be certain.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]