enhancements to the raid1 driver

enhancements to the raid1 driver

[Paul Clements]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

Hi,

I'm just beginning a project to add some new features to the raid1
driver. The planned features include:

intent log - a disk-backed bitmap to allow for quick resyncs (Peter T.
Breuer's fr1 code looks very promising)

asynchronous replication - to get acceptable performance when the backup
leg of the raid1 mirror is slow (e.g., nbd over a LAN or WAN)


I'm pretty familiar with the md and raid1 code and I've gotten far
enough along in planning to realize that I think the right approach for
making these additions to raid1 is to try, at least, not to be invasive
to the md driver itself. The existing framework of these drivers mostly
allows for that, but the one thing that would be very helpful is an
md_ioctl passthrough. By this I mean that an additional ioctl method
could be defined in the lower level raid drivers. This ioctl would be
called whenever an unrecognizable ioctl command is sent to the md
driver. It's a very simple addition (only a handful of lines). In fact,
I have already tested a patch (against 2.4.20) to do this (attached).

So, I'm wondering if the various kernel and driver maintainers would be
willing to integrate such a patch, in order to allow for work to
continue in the raid1 driver without impacting the md code, with the
ultimate goal of getting all of the raid1 changes (if the maintainers
are willing) into the mainline kernel? 

And, of course, if you have any other ideas or feedback, I'd like to
hear those, too.

Thanks,
Paul

[-- Attachment #2: md_ioctl_passthrough_2_4_20.diff --]
[-- Type: text/plain, Size: 900 bytes --]

--- include/linux/raid/md_k.h.ORIG	2003-01-10 13:14:35.000000000 -0500
+++ include/linux/raid/md_k.h	2003-01-10 13:17:26.000000000 -0500
@@ -241,6 +241,8 @@
 	int (*stop_resync)(mddev_t *mddev);
 	int (*restart_resync)(mddev_t *mddev);
 	int (*sync_request)(mddev_t *mddev, unsigned long block_nr);
+	int (*ioctl)(struct inode *inode, struct file *file, unsigned int cmd, 
+			unsigned long arg);
 };
 
 
--- drivers/md/md.c.ORIG	2003-01-10 13:05:06.000000000 -0500
+++ drivers/md/md.c	2003-01-10 13:10:01.000000000 -0500
@@ -2860,6 +2860,12 @@
 		}
 
 		default:
+			/* callout to lower level raid driver ioctl method */
+			if (mddev->pers->ioctl) {
+				err = mddev->pers->ioctl(inode, file, cmd, arg);
+				goto done_unlock;
+			}
+
 			printk(KERN_WARNING "md: %s(pid %d) used obsolete MD ioctl, "
 			       "upgrade your software to use new ictls.\n",
 			       current->comm, current->pid);

Re: enhancements to the raid1 driver

[Neil Brown]

On Friday February 14, Paul.Clements@SteelEye.com wrote:
> Hi,
> 
> I'm just beginning a project to add some new features to the raid1
> driver. The planned features include:
> 
> intent log - a disk-backed bitmap to allow for quick resyncs (Peter T.
> Breuer's fr1 code looks very promising)

An intent log would be just as useful for raid5 as for raid1, so I
think it should be largely supported by md.c rather than specific to
raid1.c

> 
> asynchronous replication - to get acceptable performance when the backup
> leg of the raid1 mirror is slow (e.g., nbd over a LAN or WAN)
> 

Hmmm. I cannot figure out exactly what would be asynchronous...  Nor
can I see how this would require an ioctl.

In general, ioctl's are seen a evils to be avoided, not added, so I am
not in favour of the patch you suggest.

Maybe if you explain more about what would be the specifics of these
ioctls that you want to pass down.

NeilBrown

Re: enhancements to the raid1 driver

[Paul Clements]

Neil,

Neil Brown wrote:
> Maybe if you explain more about what would be the specifics of these
> ioctls that you want to pass down.

Sure, no problem...
 
> > asynchronous replication - to get acceptable performance when the backup
> > leg of the raid1 mirror is slow (e.g., nbd over a LAN or WAN)
> 
> Hmmm. I cannot figure out exactly what would be asynchronous...  Nor
> can I see how this would require an ioctl.

Basically, we're trying to overcome latency penalties associated with
writing data and waiting for acknowledgements over a network (or any
other slow transport). So, all writes to the backup device(s) would be
queued, so that the writes could take place asynchronously. The size of
the queue and whether or not to enable this asynchronous mode would be
user-configurable; that's where the ioctls come in. Since user
configuration of the md driver is currently done with ioctls, this
seemed like the natural choice. Of course, I'm open to other
suggestions, if there's a better way to do this...

--
Paul