linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hubert Verstraete <hubskml@free.fr>
To: xfs@oss.sgi.com
Cc: linux-raid@vger.kernel.org
Subject: [PATCH] XFS tuning on software RAID5 partitionable array; was: MDP major registration
Date: Wed, 26 Mar 2008 19:45:01 +0100	[thread overview]
Message-ID: <47EA99AD.9060400@free.fr> (raw)
In-Reply-To: <47EA8CF4.7080201@free.fr>

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

Hi XFS list,

please find attached a patch for libdisk/mkfs.xfs which tunes XFS on 
software partitionable RAID arrays, also called mdp.

Hubert Verstraete

Hubert Verstraete wrote:
> Bill Davidsen wrote:
>> Luca Berra wrote:
>>> On Tue, Mar 25, 2008 at 05:57:06PM +0100, Hubert Verstraete wrote:
>>>> Neil Brown wrote:
>>>>> On Thursday March 13, hubskml@free.fr wrote:
>>>>>> Neil,
>>>>>>
>>>>>> What is the status of the major for the partitionable arrays ?
>>>>>
>>>>> automatically determined at runtime.
>>>>>
>>>>>> I see that it is 254, which is in the experimental section, 
>>>>>> according to the official Linux device list 
>>>>>> (http://www.lanana.org/docs/device-list/).
>>>>>> Will there be an official registration ?
>>>>>
>>>>> No. Is there any need?
>>>>
>>>> I got this question in mind when I saw that mkfs.xfs source code was 
>>>> referring to the MD major to tune its parameters on an MD device, 
>>>> while it ignores MDP devices.
>>>> If there were reasons to register MD, wouldn't they apply to MDP too ?
>>>
>>> i don't think so:
>>> bluca@percy ~ $ grep mdp /proc/devices
>>> 253 mdp
>>
>> Why is it important to have XFS tune its parameters for md and not for 
>> mdp? I don't understand your conclusion here, is tuning not needed for 
>> mdp, or so meaningless that it doesn't matter, or that XFS code reads 
>> /proc/devices, or ??? I note that device-mapper also has a dynamic 
>> major, what does XFS make of that?
> 
> It reads from /proc/devices.
> 
>> I don't know how much difference tuning makes, but if it's worth doing 
>> at all, it should be done for mdp as well, I would think.
> 
> Same thought. I wrote the patch for mkfs.xfs but did not publish it for 
> two reasons:
> 1) MD is registered but not MDP. Now I understand, it's not a problem, 
> we just need to read /proc/devices as device-mapper does.
> 2) Tuning XFS for MDP can be achieved through the mkfs.xfs options. With 
> a few lines in shell, my XFS on MDP now has the same performance as XFS 
> on MD.
> 
> Hubert
> -- 
> 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

[-- Attachment #2: xfsprogs_mdp.patch --]
[-- Type: text/x-patch, Size: 2082 bytes --]

diff -u -r xfsprogs-2.8.11/libdisk/md.c xfsprogs-2.8.11-mdp/libdisk/md.c
--- xfsprogs-2.8.11/libdisk/md.c	2006-06-26 07:01:15.000000000 +0200
+++ xfsprogs-2.8.11-mdp/libdisk/md.c	2008-03-26 20:12:38.000000000 +0100
@@ -24,8 +24,12 @@
 	dev_t		dev)
 {
 	if (major(dev) == MD_MAJOR)
-		return 1;
-	return get_driver_block_major("md", major(dev));
+		return MD_IS_MD;
+	if (get_driver_block_major("md", major(dev)))
+		return MD_IS_MD;
+	if (get_driver_block_major("mdp", major(dev)))
+		return MD_IS_MDP;
+	return 0;
 }
 
 int
@@ -37,12 +41,32 @@
 	int		*sectalign,
 	struct stat64	*sb)
 {
-	if (mnt_is_md_subvol(sb->st_rdev)) {
+	char *pc, *dfile2 = NULL;
+	int is_md;
+
+	if ((is_md = mnt_is_md_subvol(sb->st_rdev))) {
 		struct md_array_info	md;
 		int			fd;
 
+		if (is_md == MD_IS_MDP) {
+			if (!(pc = strrchr(dfile, 'd'))
+			|| !(pc = strchr(pc, 'p'))) {
+				fprintf(stderr,
+					_("Error getting MD array device from %s\n"),
+					dfile);
+				exit(1);
+			}
+			dfile2 = (char *) malloc(pc - dfile + 1);
+			if (dfile2 == NULL) {
+				fprintf(stderr,
+					_("Couldn't malloc device string\n"));
+				exit(1);
+			}
+			strncpy(dfile2, dfile, pc - dfile);
+			dfile2[pc - dfile + 1] = '\0';
+		}
 		/* Open device */
-		fd = open(dfile, O_RDONLY);
+		fd = open(dfile2 ? dfile2 : dfile, O_RDONLY);
 		if (fd == -1)
 			return 0;
 
@@ -50,10 +74,11 @@
 		if (ioctl(fd, GET_ARRAY_INFO, &md)) {
 			fprintf(stderr,
 				_("Error getting MD array info from %s\n"),
-				dfile);
+				dfile2 ? dfile2 : dfile);
 			exit(1);
 		}
 		close(fd);
+		if (dfile2) free(dfile2);
 
 		/*
 		 * Ignore levels we don't want aligned (e.g. linear)
diff -u -r xfsprogs-2.8.11/libdisk/md.h xfsprogs-2.8.11-mdp/libdisk/md.h
--- xfsprogs-2.8.11/libdisk/md.h	2006-06-26 07:01:15.000000000 +0200
+++ xfsprogs-2.8.11-mdp/libdisk/md.h	2008-03-26 20:12:10.000000000 +0100
@@ -20,6 +20,9 @@
 #define MD_MAJOR		9 /* we also check at runtime */
 #endif
 
+#define MD_IS_MD		1
+#define MD_IS_MDP		2
+
 #define GET_ARRAY_INFO          _IOR (MD_MAJOR, 0x11, struct md_array_info)
 
 #define MD_SB_CLEAN		0

  reply	other threads:[~2008-03-26 18:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 10:46 MDP major registration Hubert Verstraete
2008-03-25  5:37 ` Neil Brown
2008-03-25 16:57   ` Hubert Verstraete
2008-03-26  6:52     ` Luca Berra
2008-03-26 15:54       ` Bill Davidsen
2008-03-26 17:50         ` Hubert Verstraete
2008-03-26 18:45           ` Hubert Verstraete [this message]
2008-03-26 19:18           ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47EA99AD.9060400@free.fr \
    --to=hubskml@free.fr \
    --cc=linux-raid@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).