Date: Tue, 30 Jan 2001 21:15:12 -0800 From: Dima Dorfman <dima@unixfreak.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, mi@aldan.algebra.com, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC Message-ID: <20010131051517.C17AE3E02@bazooka.unixfreak.org> In-Reply-To: Message from John Baldwin <jhb@FreeBSD.org> of "Tue, 30 Jan 2001 19:46:13 PST." <XFMail.010130194613.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> '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 <mi@aldan.algebra.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010131051517.C17AE3E02>