From owner-freebsd-arch@FreeBSD.ORG Sat Mar 8 14:54:41 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3870D123; Sat, 8 Mar 2014 14:54:41 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08B2FA2C; Sat, 8 Mar 2014 14:54:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WMIdz-0005yr-A6; Sat, 08 Mar 2014 14:54:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s28EsTjB053504; Sat, 8 Mar 2014 07:54:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18WkOkKEtxc0xY+V/NE2Rk0 Subject: Re: Teach mdmfs about tmpfs and use tmpfs in rc scripts From: Ian Lepore To: Jia-Shiun Li In-Reply-To: References: <1394148413.1149.348.camel@revolution.hippie.lan> <1394199416.1149.367.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Mar 2014 07:54:28 -0700 Message-ID: <1394290468.1149.397.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 14:54:41 -0000 On Sat, 2014-03-08 at 22:24 +0800, Jia-Shiun Li wrote: > On Fri, Mar 7, 2014 at 9:36 PM, Ian Lepore 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. Okay, if people think that all this work should be done in the rc scripts rather than in a program, then the rc scripts need to be changed to do what I did in the program: honor existing options that make sense for tmpfs (any -o options for the mount, translate -s to size=, and don't use tmpfs if the config requests multilabel MAC). And the changes need to happen in rc.subr and in rc.initdiskless which doesn't use rc.subr. Oh, and of course, don't do any of it if tmpfs isn't available. If this isn't done, peoples' existing configurations may break (in the case of the MAC option, break in a way with potential security implications). I've gotta say, I don't understand the basic resistance to having a single unified tool for configuring a memory filesystem. -- Ian