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
next prev parent 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).