On Tue, Sep 10, 2024 at 10:06:03AM -0600, Keith Busch wrote: > Exactly. bio_integrity_add_page will use the queue's limits to decide if > it can combine pages into one vector, so appending pages through that > interface will always result in the most compact bip vector. > > This patch doesn't combine merged bio's but that's unlikely to have > mergable segments. Oh, bio_integrity_add_page uses bvec_try_merge_hw_page. That means it doesn't really work well for our stacking model, as any stacking driver can and will change these. Maybe we need to take a step back and fully apply the immutable biovec and split at final submission model to metadata? > The common use cases don't add integrity data until after the bio is > already split in __bio_split_to_limits(), and it won't be split again > after integrity is added via bio_integrity_prep(). The common path > always adds integrity in a single segment, so it's always valid. Where common case is the somewhat awful auto PI in the lowest level driver. I'd really much prefer to move to the file system adding the PI wherever possible, as that way it can actually look into it (and return it to the driver, etc). > There are just a few other users that set their own bio integrity before > submitting (the nvme and scsi target drivers), and I think both can > break from possible bio splitting, but I haven't been able to test > those. Yes. Plus dm-integrity and the new io_uring read/write with PI code that's being submitted. I plan to also support this from the file system eventually. None of these seems widely used, which I think explains the current messy state of PI as soon as merging/splitting or remapping is involved.
