On Apr 20, 2009, at 7:47 PM, Doug Ledford wrote:
And so the confusion is perpetuated. This is *not* accessing a device by name. If I give mdadm a name for my device, I don't want it doing *anything* with numbers, creating numbered symlinks, or anything else. In addition, if I tell mdadm to create something in / dev/md/ (versus it decided all on its own to create something there), then I do *NOT* want it creating *anything* in /dev/ that I didn't ask for. That, again, adds to the confusion. Of all of it though, the /proc/mdstat is the worst part as it underscores that the kernel stack is not able to think in terms of names instead of numbers.
Actually, I want to expand on this thought for a little bit. I'm obviously harping on all the symlinks and stuff that mdadm creates when you tell it what you want it to do. I know these were added for back compatibility reasons. However, the problem I have is that I work on mdadm for a living (well, sorta, I have 30+ other packages I also maintain, many of them orders of magnitude larger than mdadm, and I do kernel work, so my mdadm specific time is fairly small, but still it's paid time), and I've sat down before and tried to figure out "if I use name 'X' for my array, what device file gets created". The net result of my attempts to do that, were that I was never able to figure out just by running mdadm what the proper syntax for the name variable is/was. It always created so many symlinks to cover all possible cases that I never could get it to do what I wanted, and *just* what I wanted. In short, mdadm as it currently stands errs on the side of caution and back compatibility, but it does so to such an extent that you can never get things wrong. And if you can never get things wrong, you can never figure out how to get things *right*. We either have to create every possible compatibility symlink forever, or *sometime* we have to turn that off and just let people figure out how to get this stuff right. But right now, no one is making any progress because it's hidden by mdadm trying to cover our asses for us.
-- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband
Attachment:
PGP.sig
Description: This is a digitally signed message part
