On Mon, Feb 1, 2010 at 2:42 PM, Bill Davidsen <davidsen@xxxxxxx> wrote: > Doug Ledford wrote: >> >> On 02/01/2010 03:32 PM, Bill Davidsen wrote: >> >>> >>> Doug Ledford wrote: >>> >>>> >>>> On 01/18/2010 05:09 PM, Neil Brown wrote: >>>> >>>>> >>>>> I understand there is a problem here, but I don't like this approach >>>>> to a >>>>> solution. I'll give it more though when I get home from LCA2010 and >>>>> see >>>>> what I can come up with. >>>>> >>>> >>>> Feel free to come up with something different. But, if your solution >>>> involves maintaining an additional read/write mount area in deference to >>>> a long dead unix tradition, I'm just going to shake my head and patch >>>> your solution away to something sane. >>>> >>>> >>> >>> I don't understand you argument here. Not the one where you say you're >>> going to ignore Neil and do what you want because you can, I understand >>> that, but the "additional read/write mount area" part, isn't /var/run >>> r/w on all systems now? Could you clarify why this is "additional" here? >>> >>> >> >> It's not necessarily read/write in the initrd time frame, and putting >> the mdadm files there means it would have to be. We didn't make these >> changes because we wanted to, we made them because using mdadm raid >> arrays for the root filesystem combined with incremental assembly or >> with imsm raid devices was broken otherwise. >> >> > > Do understand that my disquiet related to this isn't because you put a > non-device in /dev, it's that you > didn't put a process PID in /var/run. And frankly, once you let (force) one > group of threads to be somewhere > else, other services will want their PIDs some other place, and anyone > maintaining an application > which presents information on what's running will need to know where that > information. > > In other words, it's not where you put it, it's where you *didn't* put it, > that seems to be an > invitation to put stuff just anywhere. Neil argues that they are not > devices, I argue that > they are PIDs. It's not as though it were a huge effort to move it after > pivot root, it's a little code > or script and in space which will be released. > > -- > Bill Davidsen <davidsen@xxxxxxx> > "We can't solve today's problems by using the same thinking we > used in creating them." - Einstein > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Thank you for stating your concern; I think knowing that a very plausible solution is obvious. # at initrd/initramfs creation time ln -s /dev/.run /var/run #initrd/initramfs script mkdir /dev/.run The usual area becomes a symlink to a memory disk .Most systems have ample memory to support a few extra tiny files there. Cleanup on reboot is automatic. Any systems that are memory constrained probably already either have a drive they could swap this data out to, or would rather save the writes from reaching flash media anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
