From owner-cvs-all Tue Jan 30 21:15:44 2001 Delivered-To: cvs-all@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 28B8537B6A6; Tue, 30 Jan 2001 21:15:18 -0800 (PST) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id C17AE3E02; Tue, 30 Jan 2001 21:15:17 -0800 (PST) Received: from unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id BA5AB3C10B; Tue, 30 Jan 2001 21:15:17 -0800 (PST) To: John Baldwin Cc: Poul-Henning Kamp , mi@aldan.algebra.com, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC In-Reply-To: Message from John Baldwin of "Tue, 30 Jan 2001 19:46:13 PST." Date: Tue, 30 Jan 2001 21:15:12 -0800 From: Dima Dorfman Message-Id: <20010131051517.C17AE3E02@bazooka.unixfreak.org> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 'mfs' would be the actual file system. Perhaps it should really be > 'ffs' then, but something else would have to newfs the disk on boot. > If you wanted it dynamic, maybe use /dev/md w/o a unit number. > /dev/null is very non-intuitive in this case. Remember that we want > to be able to do: 'mount -p > /etc/fstab' to recover a lost fstab > still if things blow up and get something close to useful. Point taken. > [/etc/fstab is for filesystems not memory disks] > > need is possibly a /etc/md.conf file that gets parsed during /etc/rc > before filesystems are mounted that will setup and created needed > memory disks. Perhaps something simple like this: vnconfig(8) actually has support for a configuration file similar to what you describe: A configuration file contains one line per device/file pair in the form: special_file regular_file [ feature ] where fields are separated by white space. The previously described ac- tion options serve to configure, enable, disable or unconfigure all de- vices in the configuration file. Obviously the exact syntax won't work as md(4) has much more functionality. > # $FreeBSD$ > # > # This file lists md(4) disks created during system initialization. > # > # device type size flags newfs > md0 swap 256m none yes > > Where setting newfs to yes implies disklabel + newfs. OTOH, this is > now somewhat complicated, and if the common case of /tmp is all we > really want to automate, having a 'tmpfs_size' variable in > /etc/rc.conf that defaults to NO along the lines of Sheldon's patch While I agree that a config file is overkill for the simple tmpfs case, it does seem like the best solution. The original concern raised by is that the existing fstab(5) entries to mount MFS disks won't work. While we can't practically make them work as is (and don't want to, as phk described), it would be nice if users who use them now didn't have to jump through hoops to regain the lost functionality. Having to hack /etc/rc to run mdconfig(8) is jumping through hoops; adding a line to md.conf or rc.conf (or whatever) is not. The question now is whether Sheldon's patch is sufficient, or whether we want to supply the option to use a configuration file. Seeing as how md(4) is supposed to entirely replace vn(4) and vnconfig(8) has support for a config file, the latter seems to imply the least POLA violation. Either way the original concern will be addressed with a relatively easy-to-implement solution. If the former (Sheldon's patch) is desired, then it needs to be tested (I can help with this) and commited; if the latter (a config file) is desired, I'll get to work on implementing it. That said, I'd still like to know what phk had in mind when he suggested that mdconfig may be changed to handle md entries in fstab(5). Perhaps I've overlooked something obvious. Regards Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message