On 9/9/2019 5:21 AM, Martin K. Petersen wrote:
Hi Max!
Hi Martin,
@@ -309,7 +308,7 @@ static void sd_set_flush_flag(struct scsi_disk *sdkp)
{
struct scsi_disk *sdkp = to_scsi_disk(dev);
- return sprintf(buf, "%u\n", sdkp->protection_type);
+ return sprintf(buf, "%u\n", sdkp->disk->protection_type);
I'm fine with moving the prepare/complete logic to the block layer. But
the block layer should always be using information from the integrity
profile. sdkp->protection_type is a SCSI disk property which is used to
pick the right integrity profile when a device is discovered and
registered.
- sdkp->protection_type is the type the disk is formatted with. This
may or may not be the same as the metadata format used by DIX and the
block layer.
ok i'll leave it as is.
- The DIX protection type (which is what matters for protection
information preparation) is encapsulated in the integrity profile
registered for the block device. The profile describes an abstract
protection format and can (at least in theory) carry non-T10 PI
protection information.
Linux currently uses the Type 1 block layer integrity profile for
devices formatted with T10 PI Types 0, 1, and 2. And the Type 3 block
layer integrity profile for devices formatted with T10 PI Type 3. This
profile is what we should be keying off of in t10-pi.c, not the
protection_type (the fact that protection_type is even there is because
the code was lifted out from sd.c).
maybe we can add profiles to type0 and type2 in the future and have more
readable code.
I would prefer to introduce .prepare_fn and .complete_fn for the Type 1
profile to match the existing .generate_fn and verify_fn. And then adapt
t10_pi_prepare() / t10_pi_complete() to plug into these new
callbacks. The need for protection_type and Type 3 matching goes away in
that case since the callbacks would only be set for the Type 1 profile.
Sounds good and simple.
I think I'll prepare dummy/empty callbacks for type3 and for nop
profiles instead of setting it to NULL.
agreed ?
static inline unsigned short
+blk_integrity_interval_shift(struct request_queue *q)
+{
+ return q->limits.logical_block_shift;
+}
+
Why not use bio_integrity_intervals() or bi->interval_exp?
I'll use bi->interval_ext.
Note that for T10 PI Type 2, the protection interval is not necessarily
the logical block size.
thanks for the review. It will make my patchset easier and it will
contain 1 patch now.
