On 04/02/2022 08:43 +0100, Milan Broz wrote:
> What's the problem here you are trying to fix?
> Even if I read linux-block posts, I do not understand the context..
1. Let me demonstrate this issue with the following example.
Given a driver which maps a bio to underlying devices with 4096 logical block
size and the mapping:
bio: sector:0, size:32, dir:WRITE
Virtual LBA Physical LBA
0 0
1 1
2 0
3 1
The Type 1 or 2 integrity is generated in bio_integrity_prep() by generate_fn
as:
Virtual LBA Virtual ref_tags
0 0
1 1
2 2
3 3
According to the mapping bio_split() would split it at 16. That would advance
bip_iter.bi_sector (aka seed, see bip_get_seed()) by 16.
Virtual LBA Physical LBA seed
Split bio
0 0 0
1 1
Updated bio: sector:16, size:16
2 0 16
3 1 +1
Remapped updated bio: sector:0
Submitting it we expect to have ref_tags remapped to the actual physical start
sector at the integrity prepare_fn and incremented by one per block of data:
Virtual LBA Physical LBA seed virtual tags ref_tags
2 0 2 2 16
3 1 +1 3 17
But we get with the current code a wrong seed (0+16) and there is no ref_tages
remapping in the block integrity prepare_fn:
Virtual LBA Physical LBA seed virtual tags ref_tags
2 0 16 2 2
3 1 +1 3 3
This IO would fail by the NVME controller with Reference Tag Check Error (84h)
because the first reference tag (2) is not equal to start LBA (16).
Martin's patch resolves this issue advancing the seed (bip_iter.bi_sector)
properly by the number of integrity intervals (2) so the tag's remapping takes
place in prepare_fn:
if (be32_to_cpu(pi->ref_tag) == virt)
pi->ref_tag = cpu_to_be32(ref_tag);
2. Browsing the code I found a snippet of advancing the integrity seed
directly, without calling bio_advance->bio_integrity_advance
I hope it does not introduce the abovementioned issue, please advise.
Dmitry
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
