[Pkg-sysvinit-devel] Bug#572733: Bug#572733: support for mounting other kernel filesystems

[Petter Reinholdtsen]

[Marco d'Itri]
> Currently the initscripts package mounts some well known kernel file
> systems like proc, sys and devpts, but there are a few others which
> AFAIK no package currently deals with:
> - cgroups (needed for accounting and management of system resources)

I thought the libcgroup package handled this one, but might be wrong.

> - hugetlbfs (provides large memory pages, an optimization useful for
>   some applications)

Did not know about this one.

> Possible solutions:
> - for each filesystem create a new package shipping an init script
>   which mounts it
> - have the initscripts package mount the filesystems 
> - have the initscripts package create the mount points for filesystems
>   listed in fstab and mounted below /dev
> - have the udev package create the mount points for filesystems
>   listed in fstab and mounted below /dev
> - others?
> 
> #3 and #4 are not incompatible with #1 and #2.

In my opinion initscripts should limit itself to mount special file
system that should be available on all or almost all installations and
that do not introduce a security problem when mounted, and leave it to
other packages to handle mounting of less common file system types.
The request for mounting debugfs by default has so far been denied, as
it have a rather special use case and can be seen as a security
problem.

I do not know cgroups and hugetlbfs well enought to know how they do
in this regard.

> If there will be no action from other maintainers then I will
> implement #4, but I am not really advocating it over the others.

For file system that should be mounted on Linux, depending on udev
mith be ok, but for file systems that also should be mounted on
kFreeBSD, I am told udev do not work and using udev is not an option.
I suspect cgroups and hugetlbfs are linux specific, but wanted to
mention the issue to be sure it is known.

On Linux, using udev is supposed to be optional, but it is getter
harder and harder to to avoid it, so I am not sure we want to spend
extra effort to make it easier to drop udev from an installation.

> Do we agree to mount these filesystems on /dev/ subdirectories?

I have no opinion on the mount point location, but would like all
distributions to agree on the same location to make it easier for
users and application writers to move applications from OS to OS.

> The upstream developers do not take a position either, but
> /dev/cgroup/ and /dev/cgroups/ are popular choices.

What are the other choices?  What do Ubuntu, SuSe, Mandriva, Gentoo
and the other distributions do?  Which mount point is most commonly
used?

> What should the default be? Mounting or not mounting the filesystems
> if they are available? Does mounting one of these filesystems has
> negative implications if it is not needed?

Adding code to initscripts for file systems that are rarely used slow
down the boot.  I suspect the slowdown is neglectabe, thought, but it
is an idea to measure it, to know how much impact it has on systems
not using these new file systems.

> I suppose that at least some RAM will be used, but is it enough to care?

I do not believe a few bytes spent by the kernel is enought to care.
I assume the kernel only allocate a few structs to keep status info on
the file systems.  If huge amount of memory is allocated, we need to
reconsider.

> If they should not be mounted by default, is fstab the best way for
> the system administrator to configure this or should an init script
> be used anyway?

Do not know.  For me it depend on how many installations should have
these file systems mounted.  If it is all or almost all -> init.d
scripts in the initscripts package and if it is some instalations ->
sysadmin can add it himself or separate pacage.

Happy hacking,
-- 
Petter Reinholdtsen