[Patch] mdadm: move mdadm.map file into /dev/md

[Patch] mdadm: move mdadm.map file into /dev/md

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 595 bytes --]

Originally, mdadm used /var/run/mdadm/mdadm.map file to store the  
temporary mappings of incrementally added devices to device names.   
Unfortunately, this breaks incremental assembly if used early in the  
booting process.  Specifically, root may still be read only.  Since  
incremental assembly is largely a udev specific feature, and udev  
needs a writable /dev tmpfs mount even when root is still read only,  
it's safer to put our mdadm.map file in /dev/md so that we can write  
to the map file no matter how early in the boot process we are  
attempting to use incremental assembly.


[-- Attachment #1.2: mdadm-3.0-mapfile.patch --]
[-- Type: application/octet-stream, Size: 4203 bytes --]

--- mdadm-3.0-devel3/Incremental.c.dev	2009-03-20 13:19:35.000000000 -0400
+++ mdadm-3.0-devel3/Incremental.c	2009-03-20 13:20:01.000000000 -0400
@@ -52,7 +52,7 @@ int Incremental(char *devname, int verbo
 	 *    a 'foreign' array.
 	 * 4/ Determine device number.
 	 * - If in mdadm.conf with std name, use that
-	 * - UUID in /var/run/mdadm.map  use that
+	 * - UUID in /dev/md/mdadm.map  use that
 	 * - If name is suggestive, use that. unless in use with different uuid.
 	 * - Choose a free, high number.
 	 * - Use a partitioned device unless strong suggestion not to.
@@ -67,7 +67,7 @@ int Incremental(char *devname, int verbo
 	 * - check one drive in array to make sure metadata is a reasonably
 	 *       close match.  Reject if not (e.g. different type)
 	 * - add the device
-	 * 6/ Make sure /var/run/mdadm.map contains this array.
+	 * 6/ Make sure /dev/md/mdadm.map contains this array.
 	 * 7/ Is there enough devices to possibly start the array?
 	 *     For a container, this means running Incremental_container.
 	 * 7a/ if not, finish with success.
@@ -315,7 +315,7 @@ int Incremental(char *devname, int verbo
 		}
 		info.array.working_disks = 1;
 		sysfs_free(sra);
-		/* 6/ Make sure /var/run/mdadm.map contains this array. */
+		/* 6/ Make sure /dev/md/mdadm.map contains this array. */
 		map_update(&map, fd2devnum(mdfd),
 			   info.text_version,
 			   info.uuid, chosen_name);
--- mdadm-3.0-devel3/mapfile.c.dev	2009-03-20 13:16:27.000000000 -0400
+++ mdadm-3.0-devel3/mapfile.c	2009-03-20 13:18:37.000000000 -0400
@@ -1,5 +1,5 @@
 /*
- * mapfile - manage /var/run/mdadm.map. Part of:
+ * mapfile - manage /dev/md/mdadm.map. Part of:
  * mdadm - manage Linux "md" devices aka RAID arrays.
  *
  * Copyright (C) 2006 Neil Brown <neilb@suse.de>
@@ -28,7 +28,7 @@
  *           Australia
  */
 
-/* /var/run/mdadm.map is used to track arrays being created in --incremental
+/* /dev/md/mdadm.map is used to track arrays being created in --incremental
  * more.  It particularly allows lookup from UUID to array device, but
  * also allows the array device name to be easily found.
  *
@@ -50,9 +50,9 @@ int map_write(struct map_ent *mel)
 	int err;
 	int subdir = 1;
 
-	f = fopen("/var/run/mdadm/map.new", "w");
+	f = fopen("/dev/md/mdadm/map.new", "w");
 	if (!f) {
-		f = fopen("/var/run/mdadm.map.new", "w");
+		f = fopen("/dev/md/mdadm.map.new", "w");
 		subdir = 0;
 	}
 	if (!f)
@@ -74,17 +74,17 @@ int map_write(struct map_ent *mel)
 	fclose(f);
 	if (err) {
 		if (subdir)
-			unlink("/var/run/mdadm/map.new");
+			unlink("/dev/md/mdadm/map.new");
 		else
-			unlink("/var/run/mdadm.map.new");
+			unlink("/dev/md/mdadm.map.new");
 		return 0;
 	}
 	if (subdir)
-		return rename("/var/run/mdadm/map.new",
-			      "/var/run/mdadm/map") == 0;
+		return rename("/dev/md/mdadm/map.new",
+			      "/dev/md/mdadm/map") == 0;
 	else
-		return rename("/var/run/mdadm.map.new",
-			      "/var/run/mdadm.map") == 0;
+		return rename("/dev/md/mdadm.map.new",
+			      "/dev/md/mdadm.map") == 0;
 }
 
 
@@ -93,9 +93,9 @@ static int lsubdir = 0;
 int map_lock(struct map_ent **melp)
 {
 	if (lfd < 0) {
-		lfd = open("/var/run/mdadm/map.lock", O_CREAT|O_RDWR, 0600);
+		lfd = open("/dev/md/mdadm/map.lock", O_CREAT|O_RDWR, 0600);
 		if (lfd < 0) {
-			lfd = open("/var/run/mdadm.map.lock", O_CREAT|O_RDWR, 0600);
+			lfd = open("/dev/md/mdadm.map.lock", O_CREAT|O_RDWR, 0600);
 			lsubdir = 0;
 		} else
 			lsubdir = 1;
@@ -118,9 +118,9 @@ void map_unlock(struct map_ent **melp)
 	if (lfd >= 0)
 		close(lfd);
 	if (lsubdir)
-		unlink("/var/run/mdadm/map.lock");
+		unlink("/dev/md/mdadm/map.lock");
 	else
-		unlink("/var/run/mdadm.map.lock");
+		unlink("/dev/md/mdadm.map.lock");
 	lfd = -1;
 }
 
@@ -149,15 +149,15 @@ void map_read(struct map_ent **melp)
 
 	*melp = NULL;
 
-	f = fopen("/var/run/mdadm/map", "r");
+	f = fopen("/dev/md/mdadm/map", "r");
 	if (!f)
-		f = fopen("/var/run/mdadm.map", "r");
+		f = fopen("/dev/md/mdadm.map", "r");
 	if (!f) {
 		RebuildMap();
-		f = fopen("/var/run/mdadm/map", "r");
+		f = fopen("/dev/md/mdadm/map", "r");
 	}
 	if (!f)
-		f = fopen("/var/run/mdadm.map", "r");
+		f = fopen("/dev/md/mdadm.map", "r");
 	if (!f)
 		return;
 

[-- Attachment #1.3: Type: text/plain, Size: 171 bytes --]



--

Doug Ledford <dledford@redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Luca Berra]

On Mon, Apr 06, 2009 at 10:52:10AM -0400, Doug Ledford wrote:
> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the temporary 
> mappings of incrementally added devices to device names.  Unfortunately, 
> this breaks incremental assembly if used early in the booting process.  
> Specifically, root may still be read only.  Since incremental assembly is 
> largely a udev specific feature, and udev needs a writable /dev tmpfs mount 
> even when root is still read only, it's safer to put our mdadm.map file in 
> /dev/md so that we can write to the map file no matter how early in the 
> boot process we are attempting to use incremental assembly.
>


since we are at it, what about using a #define for the file path?

L.




-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Goswin von Brederlow]

Doug Ledford <dledford@redhat.com> writes:

> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
> temporary mappings of incrementally added devices to device names.
> Unfortunately, this breaks incremental assembly if used early in the
> booting process.  Specifically, root may still be read only.  Since
> incremental assembly is largely a udev specific feature, and udev
> needs a writable /dev tmpfs mount even when root is still read only,
> it's safer to put our mdadm.map file in /dev/md so that we can write
> to the map file no matter how early in the boot process we are
> attempting to use incremental assembly.

What about /lib/init/rw?

You say largely udev specific so there might not be an udev running
and no tmpfs on /dev.

MfG
        Goswin

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Luca Berra]

On Tue, Apr 07, 2009 at 08:05:29AM +0200, Goswin von Brederlow wrote:
>Doug Ledford <dledford@redhat.com> writes:
>
>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>> temporary mappings of incrementally added devices to device names.
>> Unfortunately, this breaks incremental assembly if used early in the
>> booting process.  Specifically, root may still be read only.  Since
>> incremental assembly is largely a udev specific feature, and udev
>> needs a writable /dev tmpfs mount even when root is still read only,
>> it's safer to put our mdadm.map file in /dev/md so that we can write
>> to the map file no matter how early in the boot process we are
>> attempting to use incremental assembly.
>
>What about /lib/init/rw?

What is that?, i never heard of '/lib/init/rw' before

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Doug Ledford]

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

On Apr 7, 2009, at 2:05 AM, Goswin von Brederlow wrote:
> Doug Ledford <dledford@redhat.com> writes:
>
>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>> temporary mappings of incrementally added devices to device names.
>> Unfortunately, this breaks incremental assembly if used early in the
>> booting process.  Specifically, root may still be read only.  Since
>> incremental assembly is largely a udev specific feature, and udev
>> needs a writable /dev tmpfs mount even when root is still read only,
>> it's safer to put our mdadm.map file in /dev/md so that we can write
>> to the map file no matter how early in the boot process we are
>> attempting to use incremental assembly.
>
> What about /lib/init/rw?

Never heard of it.  But, if / is read-only, why wouldn't that also be  
read-only?

> You say largely udev specific so there might not be an udev running
> and no tmpfs on /dev.


Generally speaking, it's only ever going to be used by udev or run  
manually.  I doubt people will use it in things like rc.sysinit.   
However, regardless of all that, udev is started before any manual  
device bringups, so even if someone did decide to use it manually in  
rc.sysinit when root is still read only, udev will already be up by  
then.  The only exception to this would be a system that doesn't use  
udev at all, in which case they get what they get, and /dev/md/ 
mdadm.map is no better or worse than /lib/init/rw than /var/run/mdadm.

--

Doug Ledford <dledford@redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Goswin von Brederlow]

Luca Berra <bluca@comedia.it> writes:

> On Tue, Apr 07, 2009 at 08:05:29AM +0200, Goswin von Brederlow wrote:
>>Doug Ledford <dledford@redhat.com> writes:
>>
>>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>>> temporary mappings of incrementally added devices to device names.
>>> Unfortunately, this breaks incremental assembly if used early in the
>>> booting process.  Specifically, root may still be read only.  Since
>>> incremental assembly is largely a udev specific feature, and udev
>>> needs a writable /dev tmpfs mount even when root is still read only,
>>> it's safer to put our mdadm.map file in /dev/md so that we can write
>>> to the map file no matter how early in the boot process we are
>>> attempting to use incremental assembly.
>>
>>What about /lib/init/rw?
>
> What is that?, i never heard of '/lib/init/rw' before
>
> L.

At least under debian that is a tmpfs mounted in
/etc/rcS.d/S02mountkernfs.sh for programs that need to write somewhere
early in the boot process while potentially / is read-only and tmp and
var are still missing.

It even runs before /etc/rcS.d/S03udev.

MfG
        Goswin

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[NeilBrown]

On Tue, April 7, 2009 10:16 pm, Doug Ledford wrote:
> On Apr 7, 2009, at 2:05 AM, Goswin von Brederlow wrote:
>> Doug Ledford <dledford@redhat.com> writes:
>>
>>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>>> temporary mappings of incrementally added devices to device names.
>>> Unfortunately, this breaks incremental assembly if used early in the
>>> booting process.  Specifically, root may still be read only.  Since
>>> incremental assembly is largely a udev specific feature, and udev
>>> needs a writable /dev tmpfs mount even when root is still read only,
>>> it's safer to put our mdadm.map file in /dev/md so that we can write
>>> to the map file no matter how early in the boot process we are
>>> attempting to use incremental assembly.
>>
>> What about /lib/init/rw?
>
> Never heard of it.  But, if / is read-only, why wouldn't that also be
> read-only?

because a tmpfs was mounted there.  It's probably a Debian-specific
thing.

Why /var/run cannot be mounted from tmpfs nice and early too I don't know..
I understand that some people think /var/run needs to persist across
reboots to preserve ownership of directories, but they are wrong :-)
/var/run should be a tmpfs mount point very early.

I have to say that putting the map file in /dev feels very icky
to me.  It isn't a device, and so doesn't belong in /dev.
If we go around putting things somewhere convenient rather than
where they belong, we quickly end up with a mess.

So while it might be very pragmatic, I am currently dis-inclined
to take the patch.   Can you try asking your boot-script people
to make /var/run be an early tmpfs ???

NeilBrown

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Doug Ledford]

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

On Apr 7, 2009, at 5:26 PM, NeilBrown wrote:
> On Tue, April 7, 2009 10:16 pm, Doug Ledford wrote:
>> On Apr 7, 2009, at 2:05 AM, Goswin von Brederlow wrote:
>>> Doug Ledford <dledford@redhat.com> writes:
>>>
>>>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>>>> temporary mappings of incrementally added devices to device names.
>>>> Unfortunately, this breaks incremental assembly if used early in  
>>>> the
>>>> booting process.  Specifically, root may still be read only.  Since
>>>> incremental assembly is largely a udev specific feature, and udev
>>>> needs a writable /dev tmpfs mount even when root is still read  
>>>> only,
>>>> it's safer to put our mdadm.map file in /dev/md so that we can  
>>>> write
>>>> to the map file no matter how early in the boot process we are
>>>> attempting to use incremental assembly.
>>>
>>> What about /lib/init/rw?
>>
>> Never heard of it.  But, if / is read-only, why wouldn't that also be
>> read-only?
>
> because a tmpfs was mounted there.  It's probably a Debian-specific
> thing.
>
> Why /var/run cannot be mounted from tmpfs nice and early too I don't  
> know..
> I understand that some people think /var/run needs to persist across
> reboots to preserve ownership of directories, but they are wrong :-)
> /var/run should be a tmpfs mount point very early.

I disagree.  At least in our case, the reason that /var/run is a real  
directory is not to preserve ownerships (although it does do that as  
well), but to preserve security context for SELinux.

> I have to say that putting the map file in /dev feels very icky
> to me.  It isn't a device, and so doesn't belong in /dev.
> If we go around putting things somewhere convenient rather than
> where they belong, we quickly end up with a mess.

If that's the case, then all of udev's library data in /dev/.udev  
doesn't belong there either.  And as much as this may not be a device,  
it is in fact device specific in that it maps one device to another.   
It really is right along the lines of the data udev stores in .udev,  
so I don't see the ickyness.

> So while it might be very pragmatic, I am currently dis-inclined
> to take the patch.   Can you try asking your boot-script people
> to make /var/run be an early tmpfs ???

I'm betting that this stands 0 chance for F11 anyway, and I'm betting  
it would be a rather long, uphill fight to get them to agree to this  
period.

--

Doug Ledford <dledford@redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Goswin von Brederlow]

"NeilBrown" <neilb@suse.de> writes:

> On Tue, April 7, 2009 10:16 pm, Doug Ledford wrote:
>> On Apr 7, 2009, at 2:05 AM, Goswin von Brederlow wrote:
>>> Doug Ledford <dledford@redhat.com> writes:
>>>
>>>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
>>>> temporary mappings of incrementally added devices to device names.
>>>> Unfortunately, this breaks incremental assembly if used early in the
>>>> booting process.  Specifically, root may still be read only.  Since
>>>> incremental assembly is largely a udev specific feature, and udev
>>>> needs a writable /dev tmpfs mount even when root is still read only,
>>>> it's safer to put our mdadm.map file in /dev/md so that we can write
>>>> to the map file no matter how early in the boot process we are
>>>> attempting to use incremental assembly.
>>>
>>> What about /lib/init/rw?
>>
>> Never heard of it.  But, if / is read-only, why wouldn't that also be
>> read-only?
>
> because a tmpfs was mounted there.  It's probably a Debian-specific
> thing.
>
> Why /var/run cannot be mounted from tmpfs nice and early too I don't know..

Because /var is not yet mounted.

You would have to create /var/run on the / filesystem, mount a tmpfs
there early during boot. Then later you would have to move the
filesystem somwhere else (/tmp/run?), mount /var and move it back. And
you would have a race condition where /var/run is not available for a
while.

> I understand that some people think /var/run needs to persist across
> reboots to preserve ownership of directories, but they are wrong :-)
> /var/run should be a tmpfs mount point very early.

Which Ubuntu defaults to and Debian is supporting but not defaulting to.

> I have to say that putting the map file in /dev feels very icky
> to me.  It isn't a device, and so doesn't belong in /dev.
> If we go around putting things somewhere convenient rather than
> where they belong, we quickly end up with a mess.
>
> So while it might be very pragmatic, I am currently dis-inclined
> to take the patch.   Can you try asking your boot-script people
> to make /var/run be an early tmpfs ???

Having /var/run early just complicates things needlessly.

Maybe mdadm should just have

  -m, --map <file>
     Filename of the map file for incremental operations. Defaults
     to /var/run/mdadm.map. Note that the default path might not exist
     or be read-only early in the boot process in which case a
     suitable alternative must be specified.

Wouldn't that be more flexible?

Debian could then set 'MAP /lib/init/rw' in its mdadm.conf.

> NeilBrown

MfG
        Goswin

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Neil Brown]

On Wednesday April 8, goswin-v-b@web.de wrote:
> "NeilBrown" <neilb@suse.de> writes:
> >
> > Why /var/run cannot be mounted from tmpfs nice and early too I don't know..
> 
> Because /var is not yet mounted.

I guess that is a credible answer.

We really want "/volatile" rather than "/var" for holding "run" and
"locks"..  and /tmp.
I guess that is rather unlikely to happen universally.

> 
> Maybe mdadm should just have
> 
>   -m, --map <file>
>      Filename of the map file for incremental operations. Defaults
>      to /var/run/mdadm.map. Note that the default path might not exist
>      or be read-only early in the boot process in which case a
>      suitable alternative must be specified.
> 
> Wouldn't that be more flexible?
> 
> Debian could then set 'MAP /lib/init/rw' in its mdadm.conf.

Adding a config option because we cannot agree on a standard isn't my
idea of a good time...

I'm leaning towards:

 - to open for reading, if /var/run/mdadm/map doesn't exist,
   try /dev/.mdadm.map
 - to open for writing, if opening /var/run/mdadm/map and
   /var/run/mdadm.map for writing fails, try /dev/.mdadm.map

Note that I don't want to put the file in /dev/md/ as that might not
exist yet either.

So the idea is to still use /var/run/mdadm{.,/}map, but fall back on
/dev/.mdadm.map if that is the only option.

Thought?

NeilBrown

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Neil Brown]

On Tuesday April 7, dledford@redhat.com wrote:
> On Apr 7, 2009, at 5:26 PM, NeilBrown wrote:
> > On Tue, April 7, 2009 10:16 pm, Doug Ledford wrote:
> >> On Apr 7, 2009, at 2:05 AM, Goswin von Brederlow wrote:
> >>> Doug Ledford <dledford@redhat.com> writes:
> >>>
> >>>> Originally, mdadm used /var/run/mdadm/mdadm.map file to store the
> >>>> temporary mappings of incrementally added devices to device names.
> >>>> Unfortunately, this breaks incremental assembly if used early in  
> >>>> the
> >>>> booting process.  Specifically, root may still be read only.  Since
> >>>> incremental assembly is largely a udev specific feature, and udev
> >>>> needs a writable /dev tmpfs mount even when root is still read  
> >>>> only,
> >>>> it's safer to put our mdadm.map file in /dev/md so that we can  
> >>>> write
> >>>> to the map file no matter how early in the boot process we are
> >>>> attempting to use incremental assembly.
> >>>
> >>> What about /lib/init/rw?
> >>
> >> Never heard of it.  But, if / is read-only, why wouldn't that also be
> >> read-only?
> >
> > because a tmpfs was mounted there.  It's probably a Debian-specific
> > thing.
> >
> > Why /var/run cannot be mounted from tmpfs nice and early too I don't  
> > know..
> > I understand that some people think /var/run needs to persist across
> > reboots to preserve ownership of directories, but they are wrong :-)
> > /var/run should be a tmpfs mount point very early.
> 
> I disagree.  At least in our case, the reason that /var/run is a real  
> directory is not to preserve ownerships (although it does do that as  
> well), but to preserve security context for SELinux.

Ahhh... well SELinux and I have never seen eye-to-eye either :-)

> 
> > I have to say that putting the map file in /dev feels very icky
> > to me.  It isn't a device, and so doesn't belong in /dev.
> > If we go around putting things somewhere convenient rather than
> > where they belong, we quickly end up with a mess.
> 
> If that's the case, then all of udev's library data in /dev/.udev  
> doesn't belong there either.  And as much as this may not be a device,  
> it is in fact device specific in that it maps one device to another.   
> It really is right along the lines of the data udev stores in .udev,  
> so I don't see the ickyness.

You don't think that /dev/.udev is icky?

> 
> > So while it might be very pragmatic, I am currently dis-inclined
> > to take the patch.   Can you try asking your boot-script people
> > to make /var/run be an early tmpfs ???
> 
> I'm betting that this stands 0 chance for F11 anyway, and I'm betting  
> it would be a rather long, uphill fight to get them to agree to this  
> period.

And thus are poor design decisions entrenched :-(
Of course, figuring out exactly which design decision was the poor one
would not be an easy task.

NeilBrown

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Doug Ledford]

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

On Apr 8, 2009, at 2:31 AM, Neil Brown wrote:
> I'm leaning towards:
>
> - to open for reading, if /var/run/mdadm/map doesn't exist,
>   try /dev/.mdadm.map
> - to open for writing, if opening /var/run/mdadm/map and
>   /var/run/mdadm.map for writing fails, try /dev/.mdadm.map
>
> Note that I don't want to put the file in /dev/md/ as that might not
> exist yet either.
>
> So the idea is to still use /var/run/mdadm{.,/}map, but fall back on
> /dev/.mdadm.map if that is the only option.
>
> Thought?

Fine with me.


--

Doug Ledford <dledford@redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Doug Ledford]

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

On Apr 8, 2009, at 2:38 AM, Neil Brown wrote:
> On Tuesday April 7, dledford@redhat.com wrote:
>>
>> I disagree.  At least in our case, the reason that /var/run is a real
>> directory is not to preserve ownerships (although it does do that as
>> well), but to preserve security context for SELinux.
>
> Ahhh... well SELinux and I have never seen eye-to-eye either :-)

;-)

>>> I have to say that putting the map file in /dev feels very icky
>>> to me.  It isn't a device, and so doesn't belong in /dev.
>>> If we go around putting things somewhere convenient rather than
>>> where they belong, we quickly end up with a mess.
>>
>> If that's the case, then all of udev's library data in /dev/.udev
>> doesn't belong there either.  And as much as this may not be a  
>> device,
>> it is in fact device specific in that it maps one device to another.
>> It really is right along the lines of the data udev stores in .udev,
>> so I don't see the ickyness.
>
> You don't think that /dev/.udev is icky?

The whole concept of device files was a hack to enable the "everything  
is a file" semantic.  There are so many things I find icky about  
device files/enumeration in general that I find it very difficult to  
get uppity about what belongs in /dev...the whole thing is a steaming  
pile of...

--

Doug Ledford <dledford@redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Patch] mdadm: move mdadm.map file into /dev/md

[Neil Brown]

On Thursday April 9, dledford@redhat.com wrote:
> On Apr 8, 2009, at 2:31 AM, Neil Brown wrote:
> > I'm leaning towards:
> >
> > - to open for reading, if /var/run/mdadm/map doesn't exist,
> >   try /dev/.mdadm.map
> > - to open for writing, if opening /var/run/mdadm/map and
> >   /var/run/mdadm.map for writing fails, try /dev/.mdadm.map
> >
> > Note that I don't want to put the file in /dev/md/ as that might not
> > exist yet either.
> >
> > So the idea is to still use /var/run/mdadm{.,/}map, but fall back on
> > /dev/.mdadm.map if that is the only option.
> >
> > Thought?
> 
> Fine with me.

Cool.  It is done now and pushed out.

Thanks,
NeilBrown