linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: Minor mdadm fixes
Date: Tue, 23 Mar 2010 15:20:10 -0400	[thread overview]
Message-ID: <4BA9146A.2050901@redhat.com> (raw)
In-Reply-To: <20100319070153.GA12455@maude.comedia.it>

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

On 03/19/2010 03:01 AM, Luca Berra wrote:
> On Thu, Mar 18, 2010 at 10:13:06PM -0400, Doug Ledford wrote:
>> Second: mdadm-3.1.2-mapfile.patch
>> Problem: Neil's support for putting the mdadm map file wherever you need
>> it is nice, but one place in particular needs a special case.
>> Specifically, mdadm already creates /dev/md if needed to store symlinks,
>> or in the case of mdmon needing to create pid/sock files (if ALT_RUN is
> why on earth do you want to set ALT_RUN=/dev/md ?

Because on Fedora /lib/init/rw doesn't exist, and neither does any other
early rw area other than /dev, and it's too late to create a new one, so
I need to use someplace in /dev.  However, I agree with Neil that if you
are hiding things under . names then you are admitting something isn't
right.  So, I'm perfectly happy putting the map file in /dev/md as I
think it has a perfect right to exist there.

> it is messy enough as it is, let's keep assuming /dev/md contains only
> array device files.

I don't know how many arrays you have on your system, but I would hardly
call /dev/md messy.

> besides that you will discover that the only way to make mdmon work is
> setting VAR_RUN and ALT_RUN to the same value,

[ citation needed ]

> something we can
> guarantee to be writable even in the direst situation, and i'd keep
> /dev/.mdadm

There is no guarantee /dev/.mdadm exists on a clean install, where as I
have made sure that all possible places that might need /dev/md will
create it if it doesn't exist.  Hence, the direst of situations is
handled better with /dev/md than with /dev/.mdadm

>> Fourth: mdadm-3.1.2-mapname.patch
>> Feature: If we are able to easily select the location of the mapfile via
>> the use of ALT_RUN at compile time, it makes sense to also be able to
> this "hunt the mapfile" thing is already ugly as it is, why do we need
> an ALT_MAPNAME?

Because /dev/md/map is too easy a name to conflict with a legitimate md
array device name, and that's what it defaults to if you set ALT_RUN to
/dev/md.

> if there was any value (except for allowing to set
> ALT_RUN to /dev/md) to having the mapfile named differently, just force
> it to be called mdadm.map everywere (or incremental.map so the name
> reflects the need for the file existance)

Except I set it to md-device-map.  Aside from not conflicting with md
device names, the map file name is mostly irrelevant except to indicate
to people perusing the directory what the file is for as nothing uses it
besides mdadm and mdadm will gladly use it with whatever name you call
it as it both creates and uses the file from the same compile time
configuration setting.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-03-23 19:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19  2:13 Minor mdadm fixes Doug Ledford
2010-03-19  7:01 ` Luca Berra
2010-03-23 19:20   ` Doug Ledford [this message]
2010-03-23 20:28     ` Luca Berra
2010-03-24  0:27 ` Neil Brown
2010-03-24 17:48   ` Doug Ledford
  -- strict thread matches above, loose matches on Subject: below --
2010-01-11 20:38 Doug Ledford
2010-01-12  0:49 ` Mr. James W. Laferriere
2010-01-12  3:10   ` Andre Noll
2010-01-12  3:36     ` Doug Ledford
2010-01-12  4:39       ` Andre Noll
2010-01-12  4:46         ` Doug Ledford
2010-01-12  5:21           ` Andre Noll
2010-01-18 22:05 ` Neil Brown

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=4BA9146A.2050901@redhat.com \
    --to=dledford@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    /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).