[PATCH] md: Add support for data integrity to MD

[PATCH] md: Add support for data integrity to MD

[Martin K. Petersen]

If all subdevices support the same protection format the MD device is
flagged as capable.

Depends on d7533ad0e132f92e75c1b2eb7c26387b25a583c1 being reverted.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
---
 drivers/md/md.c |   32 +++++++++++++++++++++++++++++++-
 1 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 45521da..b038581 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3497,7 +3497,7 @@ static int do_md_run(mddev_t * mddev)
 	int err;
 	int chunk_size;
 	struct list_head *tmp;
-	mdk_rdev_t *rdev;
+	mdk_rdev_t *rdev, *prev;
 	struct gendisk *disk;
 	struct mdk_personality *pers;
 	char b[BDEVNAME_SIZE];
@@ -3759,6 +3759,35 @@ static int do_md_run(mddev_t * mddev)
 	sysfs_notify(&mddev->kobj, NULL, "sync_action");
 	sysfs_notify(&mddev->kobj, NULL, "degraded");
 	kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
+
+	/* Data integrity passthrough not supported on RAID 4, 5 and 6 */
+	if (pers->level >= 4 && pers->level <= 6)
+		return 0;
+
+	prev = NULL;
+
+	rdev_for_each(rdev, tmp, mddev) {
+
+		if (prev && blk_integrity_compare(prev->bdev, rdev->bdev) < 0) {
+			printk(KERN_ERR "%s: %s %s Integrity mismatch!\n",
+			       __func__, prev->bdev->bd_disk->disk_name,
+			       rdev->bdev->bd_disk->disk_name);
+			return 0;
+		}
+
+		prev = rdev;
+	}
+
+	if (prev && bdev_get_integrity(prev->bdev)) {
+
+		if (blk_integrity_register(disk, prev->bdev->bd_disk->integrity))
+			printk(KERN_ERR "%s: %s Could not register integrity!\n",
+			       __func__, disk->disk_name);
+		else
+			printk(KERN_INFO "Enabling data integrity on %s\n",
+			       disk->disk_name);
+	}
+
 	return 0;
 }
 
@@ -3947,6 +3976,7 @@ static int do_md_stop(mddev_t * mddev, int mode, int is_open)
 		printk(KERN_INFO "md: %s switched to read-only mode.\n",
 			mdname(mddev));
 	err = 0;
+	blk_integrity_unregister(disk);
 	md_new_event(mddev);
 	sysfs_notify(&mddev->kobj, NULL, "array_state");
 out:
-- 
1.5.5.1

Re: [PATCH] md: Add support for data integrity to MD

[Dan Williams]

On Sat, Sep 20, 2008 at 5:18 PM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
> If all subdevices support the same protection format the MD device is
> flagged as capable.
>
> Depends on d7533ad0e132f92e75c1b2eb7c26387b25a583c1 being reverted.
>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> ---
>  drivers/md/md.c |   32 +++++++++++++++++++++++++++++++-
>  1 files changed, 31 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 45521da..b038581 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -3497,7 +3497,7 @@ static int do_md_run(mddev_t * mddev)
>        int err;
>        int chunk_size;
>        struct list_head *tmp;
> -       mdk_rdev_t *rdev;
> +       mdk_rdev_t *rdev, *prev;
>        struct gendisk *disk;
>        struct mdk_personality *pers;
>        char b[BDEVNAME_SIZE];
> @@ -3759,6 +3759,35 @@ static int do_md_run(mddev_t * mddev)
>        sysfs_notify(&mddev->kobj, NULL, "sync_action");
>        sysfs_notify(&mddev->kobj, NULL, "degraded");
>        kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
> +
> +       /* Data integrity passthrough not supported on RAID 4, 5 and 6 */
> +       if (pers->level >= 4 && pers->level <= 6)
> +               return 0;

Do you have a reference to the issues in supporting this?

Thanks,
Dan

Re: [PATCH] md: Add support for data integrity to MD

[Martin K. Petersen]

>>>>> "Dan" == Dan Williams <dan.j.williams@gmail.com> writes:

>> + /* Data integrity passthrough not supported on RAID 4, 5 and 6 */
>> + if (pers->level >= 4 && pers->level <= 6) + return 0;

Dan> Do you have a reference to the issues in supporting this?

Not really.

The protection information is an extra 8-bytes of stuff per sector.
But it comes down in a different buffer.  To do R-M-W effectively
we'll have to maintain a separate protection information stripe cache.
And we'll have to generate DIF checksums and reference tags for the
parity sectors going out.

Quite frankly it's a lot of ick and I haven't completely wrapped my
head around it yet.

-- 
Martin K. Petersen	Oracle Linux Engineering

Stable versions of mdadm ...

[berk walker]

Neil - is there an history file of "Stable" mdadm releases?  or are 
there any?  I would trust YOU [and yours] more than canned firmware.

Hey - you should buy US, the $ [USD] isn't worth squat - this is the 1st 
time in my memory [I'm 65] that we actually don't have a trade deficit.

berk

Re: Stable versions of mdadm ...

[Bill Davidsen]

berk walker wrote:
> Neil - is there an history file of "Stable" mdadm releases?  or are 
> there any?  I would trust YOU [and yours] more than canned firmware.
>
With one exception long ago I don't think I would regard any as 
"unstable." Regular updates do show up, of course, but unless you are 
doing something really unusual you should have no issues. Usually the 
one the distribution ships is well tested, so unless you need some very 
recent feature there's no need for the bleeding edge.
> Hey - you should buy US, the $ [USD] isn't worth squat - this is the 
> 1st time in my memory [I'm 65] that we actually don't have a trade 
> deficit.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 

Re: Stable versions of mdadm ...

[berk walker]

Bill Davidsen wrote:
> berk walker wrote:
>> Neil - is there an history file of "Stable" mdadm releases?  or are 
>> there any?  I would trust YOU [and yours] more than canned firmware.
>>
> With one exception long ago I don't think I would regard any as 
> "unstable." Regular updates do show up, of course, but unless you are 
> doing something really unusual you should have no issues. Usually the 
> one the distribution ships is well tested, so unless you need some 
> very recent feature there's no need for the bleeding edge.
>> Hey - you should buy US, the $ [USD] isn't worth squat - this is the 
>> 1st time in my memory [I'm 65] that we actually don't have a trade 
>> deficit.
>
I should have said versions/releases vs. kernel levels.  And Bill - - 
90% of this newsgroup/forum IS either about what is "broke" or patches 
to fix it.  Sir, I have been here for YEARS.  And I have NO intention to 
say anything which might be taken as detrimental or negative here.  I 
said have - I meant had, eh?

Mea culpa.
b-

Re: [PATCH] md: Add support for data integrity to MD

[Neil Brown]

On Saturday September 20, martin.petersen@oracle.com wrote:
> 
> If all subdevices support the same protection format the MD device is
> flagged as capable.

But what if we subsequently add a different device to that array which
uses a different protection format.   Would we be able to tell the
filesystem that integrity protection isn't available any more?
Or can we detect if the filesystem is using integrity protection, and
reject the new device if it doesn't match?

In either case, some extra handling is needed in bind_rdev_to_array.

NeilBrown


> 
> Depends on d7533ad0e132f92e75c1b2eb7c26387b25a583c1 being reverted.
> 
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> ---
>  drivers/md/md.c |   32 +++++++++++++++++++++++++++++++-
>  1 files changed, 31 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 45521da..b038581 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -3497,7 +3497,7 @@ static int do_md_run(mddev_t * mddev)
>  	int err;
>  	int chunk_size;
>  	struct list_head *tmp;
> -	mdk_rdev_t *rdev;
> +	mdk_rdev_t *rdev, *prev;
>  	struct gendisk *disk;
>  	struct mdk_personality *pers;
>  	char b[BDEVNAME_SIZE];
> @@ -3759,6 +3759,35 @@ static int do_md_run(mddev_t * mddev)
>  	sysfs_notify(&mddev->kobj, NULL, "sync_action");
>  	sysfs_notify(&mddev->kobj, NULL, "degraded");
>  	kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
> +
> +	/* Data integrity passthrough not supported on RAID 4, 5 and 6 */
> +	if (pers->level >= 4 && pers->level <= 6)
> +		return 0;
> +
> +	prev = NULL;
> +
> +	rdev_for_each(rdev, tmp, mddev) {
> +
> +		if (prev && blk_integrity_compare(prev->bdev, rdev->bdev) < 0) {
> +			printk(KERN_ERR "%s: %s %s Integrity mismatch!\n",
> +			       __func__, prev->bdev->bd_disk->disk_name,
> +			       rdev->bdev->bd_disk->disk_name);
> +			return 0;
> +		}
> +
> +		prev = rdev;
> +	}
> +
> +	if (prev && bdev_get_integrity(prev->bdev)) {
> +
> +		if (blk_integrity_register(disk, prev->bdev->bd_disk->integrity))
> +			printk(KERN_ERR "%s: %s Could not register integrity!\n",
> +			       __func__, disk->disk_name);
> +		else
> +			printk(KERN_INFO "Enabling data integrity on %s\n",
> +			       disk->disk_name);
> +	}
> +
>  	return 0;
>  }
>  
> @@ -3947,6 +3976,7 @@ static int do_md_stop(mddev_t * mddev, int mode, int is_open)
>  		printk(KERN_INFO "md: %s switched to read-only mode.\n",
>  			mdname(mddev));
>  	err = 0;
> +	blk_integrity_unregister(disk);
>  	md_new_event(mddev);
>  	sysfs_notify(&mddev->kobj, NULL, "array_state");
>  out:
> -- 
> 1.5.5.1
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] md: Add support for data integrity to MD

[Martin K. Petersen]

>>>>> "Neil" == Neil Brown <neilb@suse.de> writes:

Neil> But what if we subsequently add a different device to that array
Neil> which uses a different protection format.  Would we be able to
Neil> tell the filesystem that integrity protection isn't available
Neil> any more?  Or can we detect if the filesystem is using integrity
Neil> protection, and reject the new device if it doesn't match?

Generally the filesystem will look at the block device's integrity
profile every time it prepares an I/O.  So if we add a subdevice and
detect a mismatch the mddev integrity profile should be removed.


Neil> In either case, some extra handling is needed in
Neil> bind_rdev_to_array.

This code has been sitting in my patch queue for several months
waiting for the core of the integrity stuff to go in.  So I'm a bit
fuzzy on the details.  I'll take a look...

-- 
Martin K. Petersen	Oracle Linux Engineering