Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Mar 2014 17:19:45 +0200
From:      Konstantin Belousov <kostikbel@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:  <20140307151945.GK24664@kib.kiev.ua>
In-Reply-To: <1394148413.1149.348.camel@revolution.hippie.lan>
References:  <1394148413.1149.348.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--SpYKH75o2aPywVKk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 06, 2014 at 04:26:53PM -0700, Ian Lepore wrote:
> A recent discussion on arm@ about using tmpfs instead of md(4) spurred
> me to do something I've been wanting to do for a while:  enhance mdmfs
> so that it can configure tmpfs as well as md+ffs, and update the rc
> scripts to make use the the feature.
>=20
> Attached are diffs to do this (man page updates not in there yet).
>=20
> mdmfs recognizes two new values for the md-device argument: tmpfs and
> auto.  If you request 'tmpfs' you get it, or it fails if tmpfs is not
> present in the kernel.  If you request 'auto' it will use tmpfs if it's
> present in the kernel and the other options don't include multilabel MAC
> (which tmpfs doesn't handle, as near as I can tell).  Other options
> which have no meaning with tmpfs (such as setting the number of inodes)
> are silently ignored.
>=20
> The rc scripts are updated to add a new mfs_type knob, which defaults to
> "auto".  This in effect automatically updates folks to use tmpfs instead
> of md as long as it's present and they aren't using the one option that
> forbids it (multilabel MAC).
>=20
> Thoughts?
>=20
> -- Ian
>=20

> Index: sys/fs/tmpfs/tmpfs_vfsops.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- sys/fs/tmpfs/tmpfs_vfsops.c	(revision 262759)
> +++ sys/fs/tmpfs/tmpfs_vfsops.c	(working copy)
> @@ -60,6 +60,8 @@ __FBSDID("$FreeBSD$");
> =20
>  #include <fs/tmpfs/tmpfs.h>
> =20
> +FEATURE(tmpfs, "Efficient memory file system");
> +
The existing way to check for the presence of the filesystem module
in the kernel is sysctl vfs.conflist or getvfsbyname(3) wrapper around
it.  I suspect that the interface is unknown because the information
about fs module presence in kernel is pretty much useless: nmount(2)
syscall auto-loads required fs module if not already present.

That said, the feature for tmpfs is redundand and should not be added.

I do not see adding the ability to issue 'mount -t tmpfs ...' command
to mdmfs(8) as right approach.  The helper is already complicated and
its single-purpose functionality of newfs-ing md(4) IMO should be left
as is.  If you want to to have /var on tmpfs, why not change rc.d/var ?
It would be much simpler, since the change would be one-liner for
mount_md line.

--SpYKH75o2aPywVKk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBAgAGBQJTGeOQAAoJEJDCuSvBvK1BTAIP/139L6LJqJHByfKHXdILpHkt
rFoP+tidt0Q9gXbko5wQLCSgujLPTe/y0KF1nz46EyJanqf3iwmz+CHKXfdOxBcy
Gefrypx3WAHCLkgAOIIyFecTFaTh7TKMy1KTtpstj4a3pIKKwgJUd0RC7xZQB8it
6tM7DDIlDxP4Sribio0sSgjzxDY0pTQyKRq5gDz/eV2f3/vxBSm91O4ew+0tZTXy
0Cy1mqPlwZ5zC3Oh3XufSa5SPz5c22LCN0Z29gizhnDkreeGWZO3THPMWU8kZ31u
jb+VegWA5k4uAkcmAbJNvk4fRTqAal8pBSLhIbowFz4Bppgm8kIOTEIR75R+Rccz
MW6V9yt316+ngzuUwHNlB1lgPclXCv/beskbLZQ3e3uSaCU8pNc1pxNWmJtTL7p7
dfugxnRpAdizoYfMQsABf1fjQH8oQ08PIJsGFqdP2gP9AHUgtzI7p3Yg2XQiaaaJ
unhyrYMEezrTt2bc9gmOAqDiOX6GepLjEn6lR0wq9kNXYswfZBHjvdafvivTaWaq
oLLqjKiXNHagFqfPQtIb5WPBRQjPtCWCw1nTBiY7O8FR+T5HRiNqlgvwZ9z4OEqI
TeemIfL39l+7n7IT8cHlRPyOeEeBfLMQqBLkv7WyvkNcvDdR7iCtbyO2CDXkhV60
qMhfOZBqh7rEeyCz4bBh
=y87W
-----END PGP SIGNATURE-----

--SpYKH75o2aPywVKk--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140307151945.GK24664>