Re: [Patch] mdadm ignoring homehost?

[Doug Ledford <dledford@redhat.com>]

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

On Apr 18, 2009, at 4:12 AM, Luca Berra wrote:
> On Fri, Apr 17, 2009 at 02:17:47PM -0400, Doug Ledford wrote:
>> This appears to be the difference between a server setup and a  
>> desktop setup.  Server admins want to list things and only have  
>> known actions happen.  Desktop people want things to "just work".   
>> I've had several people tell me they thought the idea of mdadm.conf  
>> was completely out of date and it should just go away entirely.   
>> Not saying I agree, just letting you know what I get.
> uhm, udev should be able to assemble an array without mdadm.conf, not
> that i like it

It does, the question is whether or not it should honor the preferred  
minor when it assembles an array not in mdadm.conf.

>>> Parts of what you are proposing seem to involve expecting people to
>>> take a middle ground with some arrays listed in mdadm.conf and other
>>> that aren't.
>>
>> I do this myself FWIW.  My / and /boot arrays are in mdadm.conf,  
>> but arrays that I plug in via USB, eSATA, etc. are not.
>>
>>> I'm not sure I'm happy with expecting people to do that
>>> (though of course I'm happy to support it).
>>
>> I really don't expect them to per se.  More like it's the *safe*  
>> thing to do.  If you ever have a conflict in names, the one in the  
>> file wins.  If you ever have a conflict in names without one of  
>> them in the file, then it's whoever got there first.  In that  
>> sense, mdadm.conf is just a backup for me.  Well, that and mkinitrd  
>> doesn't do incremental assembly, so it's needed for boot in my  
>> case.  But that could be changed.
> yes, if we ensure it will mount the correct array :)

With my patch (which Neil didn't like), it does.

> i was wondering about indicating our preference to policy in  
> mdadm.conf
> ie
>
> POLICY {dynamic|preferred|strict}
>
> dynamic: assemble anything you find, naming policy first come first
> served. this might be the only line in mdadm.conf
>
> preferred (in need of a better name): arrays defined here have
> precedence over dynamically found arrays
>
> strict: if it ain't here, just ignore it
>
> ....
>> This is a bad idea, and just reinforces my thought that we  
>> shouldn't be paying attention to homehost.  Amongst the most  
>> important aspects are machines that are booted up, installed, raid  
>> arrays created during install, then shut down and moved, likely  
>> changing dhcp hostnames in the process.  Now all your homehosts  
>> belong to some hostname in some IT guys install network instead of  
>> in your final network.  At install time, it's actually fairly  
>> common that the hostname is not yet set, especially at raid array  
>> creation time.
> i never found much use for homehost, i would prefer to have a stricter
> locking mechanism for shared storage (maybe integration of cman
> locking???) and leave the desktop world with randomic names.
> If you get the first case wrong you risk damaging data.
> If you get the array name wrong on a desktop i expect the luser will
> never even notice as long a windows pops up showing the filesystem
> contents :P


I've been thinking about this, and this is the method I would suggest.

Add two new keywords to the mdadm.conf file:

ASSEMBLE
INCREMENTAL

Allow each of those keywords to have one of three set values:
None - Don't attempt to assemble any arrays regardless of whether or  
not they are in the mdadm.conf file or not
Known - Only assemble arrays with a matching array line
All - Attempt to assemble any array found

The combination of the two options and the three settings would allow  
you to control mdadm behavior for both array assembly modes  
independently.  That, combined with my previous patch, should allow  
arrays to assemble well, with known names, allow you to control auto  
assembly by udev, and in the event that your machine just exports  
volumes to other machines for their use, stop assembly entirely.

--

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 --]