Date: Sat, 8 Mar 2014 22:24:07 +0800 From: Jia-Shiun Li <jiashiun@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-rc@freebsd.org, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Teach mdmfs about tmpfs and use tmpfs in rc scripts Message-ID: <CAHNYxxM3F_aizj%2BJKzqCqiq6o1PEuvG05ZCYRxgGdhnWdSZW0g@mail.gmail.com> In-Reply-To: <1394199416.1149.367.camel@revolution.hippie.lan> References: <1394148413.1149.348.camel@revolution.hippie.lan> <CAHNYxxNSjNMg8hMGL2d%2B223P6gwFJUU%2Bdxnbqcz08SR5A-JDFQ@mail.gmail.com> <1394199416.1149.367.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 7, 2014 at 9:36 PM, Ian Lepore <ian@freebsd.org> wrote: > I'm not sure what you mean. If the device on the command line is md the > program behaves as it always has. If you ask for 'auto' you get the > "best" memory filesystem available for some definition of "best". If > you don't trust someone else's definition of best (like you need failure > at allocation time) then you choose the one that behaves the way you > like. ehh.. sorry read too fast and did not realize you 'added' new options in addition to existing 'md'. My bad. I did not use mdmfs often. My understanding is that it is the help to simplify mdconfig-newfs-mount process to replace a one-step mount_mfs. Then I agree with Konstantin, it does not look too appealing. If the goal is to merge all memory-backed fs to single versatile command, then the proposal does the job. Otherwise one mount_tmpfs comamnd does all user needs for tmpfs, and I am not sure the auto decision is good if user did not know what he need or care. It seems better to leave the decision to user. And for rc usage, I think we can just change it to tmpfs. If in the future tmpfs grows ability to populate content with e.g. a cpio archive at boot time or passed from command line, md usage can be further replaced. -Jia-Shiun.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHNYxxM3F_aizj%2BJKzqCqiq6o1PEuvG05ZCYRxgGdhnWdSZW0g>