lkml.org 
[lkml]   [2012]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: /etc/fstab.d yes or not
On Fri, Jan 20, 2012 at 17:22, Roger Leigh <rleigh@codelibre.net> wrote:
> On Fri, Jan 20, 2012 at 05:13:12PM +0100, Kay Sievers wrote:
>> On Fri, Jan 20, 2012 at 16:49, Roger Leigh <rleigh@codelibre.net> wrote:
>> > On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
>> >>  I'd like to add support for /etc/fstab.d to libmount. The library is
>> >>  currently used by mount, umount and mount.nfs. The goal is to use it
>> >>  on more places.
>> >>
>> >>  The /etc/fstab.d directory has been requested by people who maintains
>> >>  large number of mountpoints etc.
>> >>
>> >>  The directory is not replacement for /etc/fstab, it's additional place
>> >>  where you can describe your filesystems.
>> >
>> > As a general comment, I would like to use fstab.d for replacing
>> > the initscripts which mount kernel filesystems in Debian initscripts
>> > (sysvinit).  We currently hardcode the logic to mount each filesystem
>> > and additionally hardcode the defaults, and permit the defaults to
>> > be overridden by the user via /etc/default/* or via entries in
>> > /etc/fstab.  This could be done much more straightforwardly using
>> > entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.
>>
>> It is just very wrong to expose kernel filesystems to system mounts.
>> Please invent your own config if you want that for packaging. The
>> kernel filesystems do not belong in fstab, and for the same reason not
>> in fstab.d/.
>
> To be fair, these can be split into two categories: kernel filesystems
> such as procfs, sysfs etc., and special-purpose tmpfs mounts.  The
> former could be kept in the init scripts, but the latter are commonly
> required to be customised (or disabled) by admins, and the fstab format
> is the natural way to express this.  This would include tmpfs mounts
> for e.g. /run, /run/lock, /run/shm, potentially /tmp] and others, each
> of which has separate limits.
>
> Inventing custom file formats for these (as is the current situation)
> is both opaque to the admin and less amenable to preservation/upgrading
> of the admins customisations and the defaults.

I'm not talking about custom file formats, better just add a mount -c,
and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
needs.

This is nothing really to share between systemd and systemv here. This
problem just does not exist for systemd.

And for systemv it should not be solved in mount(8), but in a systemv
specific part.

A change in common tools at that level breaks much more than it solves.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-01-20 19:07    [W:0.062 / U:21.396 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site