On Mar 15, 2007, at 1:12 PM, Frans Pop wrote:
On Thursday 15 March 2007 17:44, Colin Watson wrote:
Personally I also feel that all possible solutions effectively make
/etc/fstab unreadable and unmaintainable.
The approach we took in Ubuntu was to put comments above each UUID
entry in /etc/fstab documenting which traditional device name they
corresponded to at the point of installation. Of course this can get
out of date, but I don't think there's really any sensible way around
that.
My main point is not that the UUID itself is not readable, but
rather that
the lines get way too long and, depending on your editor (settings),
either get wrapped or disappear off screen. You loose the easy
overview
of what's in fstab.
/etc/fstab used to be fairly maintainable because the info could be
kept
in columns fairly easily for most cases and because the info would
mostly
fit on one line [1].
IMO with a switch to UUIDs we are going to need an fstab editor
(console
based) that:
- does the translation to the "normal" device names on the fly (and
thus
does always reflect the actual situation)
- provides different 'views' of what's in fstab
- allows to select what representation for the file system should be
used in the fstab (traditional, path, uuid, id, ...)
- allows to set mount point, type, mount options, etc.
- sorts partitions into a logical order
- maybe knows about removable devices
- has a simple interface to add new entries for e.g. USB sticks
- ...
[1] Yeah, I know this is not true for NFS volumes and if a lot of
options
are used, but in general it was true.
If you're going to all the trouble of a smart fstab editor, why not
simply define a more modern format (e.g. like that of dhcpd.conf) for
the information that can accommodate line breaks and nesting. Change
the name to something else, don't call it fstab; if the new file
doesn't exist the mount command (and the rest of them that currently
read fstab) will default to /etc/fstab if present.
The biggest problem will be identifying all the places where fstab is
currently *assumed* to be present and making them all use the new
file. A library is probably needed that does the deciding of which
format to use.
Are there POSIX/LSB/etc ramifications?
just a thought,
Rick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]