Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: > This is a pretty big increase in the bio_integrity_payload size, > but I guess we can't get around it.. Yes, everybody hate this solution, me too, but I've stated with other approach and it is appeaded to be very ugly. My idea was that we have two types of iterator incrementors: bio_advance() and bio_xx_complete, First one is called during split, later is called on completion ( req_bio_endio() ) . So we can add new field "bi_done" to iterator which has similar meaning as bi_bvec_done, but at full iterator scope. It is incremented during completion, but before end_io. Chain bios will propogate bi_done to parent bio to parent one. On ->vefify_fn() iterator will be rewinded (counter part of bvec_advance) to iter->bi_done bytes, so we will get oritinal iterator. I've even prepare a patch for this idea and it looks big and awful. Even more it does not works if chained bios overlapts (raid1,raid10, etc). But... at the time I've wrote this email I've realized that I do not care about what happen with chained bios. The only thing is important is parent bio and how far it was advanced. If bi_done is incremented inside bvec_iter_advance() I can be shure that at the moment ->bi_end_io() original position can be restored by rewinding back to io_done bytes. I'll try to implement this. > > Reviewed-by: Christoph Hellwig <hch@xxxxxx>
