rfc: converting /etc/mtab to a symlink

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Michał Górny-5
Dnia 2013-10-14, o godz. 09:26:43
Richard Yao <[hidden email]> napisał(a):

> On Oct 14, 2013, at 9:19 AM, Rich Freeman <[hidden email]> wrote:
>
> > On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <[hidden email]> wrote:
> >> I don't see a compelling case being made for why we should make this
> >> change apart from "all the other distros are doing it", and quite a
> >> few reasons why we shouldn't. I'm open to being convinced, so please
> >> tell me why this is good for Gentoo users.
> >
> > So far I've seen a reference to a bug associated with a bunch of
> > systemd issues when it isn't mounted, and the point that many things
> > break in namespaces without the symlink, since /etc/mtab does not
> > reflect the state of the namespace.  The latter in particular seems
> > like a pretty fundamental limitation - the very concept of /etc/mtab
> > is that mounts are global, and the design of linux is that mounts are
> > NOT global.
>
> Why should this not be treated as a systemd bug?
Is it a Linux kernel bug that it supports mount namespaces? Since
userspace clearly wasn't designed for that 20 years ago, so Linux
clearly has a bug supporting that!

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.

With that said, how does changing things benefit/affect users, especially non-systemd users?

On Oct 14, 2013, at 9:36 AM, Michał Górny <[hidden email]> wrote:

> Dnia 2013-10-14, o godz. 09:26:43
> Richard Yao <[hidden email]> napisał(a):
>
>> On Oct 14, 2013, at 9:19 AM, Rich Freeman <[hidden email]> wrote:
>>
>>> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <[hidden email]> wrote:
>>>> I don't see a compelling case being made for why we should make this
>>>> change apart from "all the other distros are doing it", and quite a
>>>> few reasons why we shouldn't. I'm open to being convinced, so please
>>>> tell me why this is good for Gentoo users.
>>>
>>> So far I've seen a reference to a bug associated with a bunch of
>>> systemd issues when it isn't mounted, and the point that many things
>>> break in namespaces without the symlink, since /etc/mtab does not
>>> reflect the state of the namespace.  The latter in particular seems
>>> like a pretty fundamental limitation - the very concept of /etc/mtab
>>> is that mounts are global, and the design of linux is that mounts are
>>> NOT global.
>>
>> Why should this not be treated as a systemd bug?
>
> Is it a Linux kernel bug that it supports mount namespaces? Since
> userspace clearly wasn't designed for that 20 years ago, so Linux
> clearly has a bug supporting that!
>
> --
> Best regards,
> Michał Górny

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <[hidden email]> wrote:
> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>
> With that said, how does changing things benefit/affect users, especially non-systemd users?

Better support for namespaces, for one.

If this is actually going to actually break something, by all means
speak up.  Otherwise this really comes across as the whole
I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
/etc/mtab a symlink, and if down the road something doesn't work as a
result feel free to fork it unless you can convince somebody else to
make it work.  So far the only concrete issues that have been raised
seem minor - pertaining to NFS and PAM (both having solutions
available).

If this causes trouble for the FreeBSD folks I'm interested in what
kinds of compromises can be reached.  I think a challenge is that
Linux and FreeBSD seem to be very slowly diverging - for software that
lives near the kernel/userspace boundary that could make things
interesting.  There doesn't seem to be much desire to limit Linux
distros to purely POSIX behavior.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
On 10/14/2013 10:11 AM, Rich Freeman wrote:

> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <[hidden email]> wrote:
>> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>>
>> With that said, how does changing things benefit/affect users, especially non-systemd users?
>
> Better support for namespaces, for one.
>
> If this is actually going to actually break something, by all means
> speak up.  Otherwise this really comes across as the whole
> I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
> /etc/mtab a symlink, and if down the road something doesn't work as a
> result feel free to fork it unless you can convince somebody else to
> make it work.  So far the only concrete issues that have been raised
> seem minor - pertaining to NFS and PAM (both having solutions
> available).
>
> If this causes trouble for the FreeBSD folks I'm interested in what
> kinds of compromises can be reached.  I think a challenge is that
> Linux and FreeBSD seem to be very slowly diverging - for software that
> lives near the kernel/userspace boundary that could make things
> interesting.  There doesn't seem to be much desire to limit Linux
> distros to purely POSIX behavior.
>
> Rich
>
My main concern is that some of the configure flags being proposed could
make packages that worked on Gentoo FreeBSD stop working there. I am not
making changes, but I think that there should be some benefit and that
care should be taken not to break things for everyone else.

That being said, mgorny said that this adds support for mount
namespaces, but I have yet to hear an explanation of what that actually
means. What are the use cases?


signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

William Hubbs
In reply to this post by pva0xd
On Mon, Oct 14, 2013 at 10:00:03AM +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> >
> > Are there any remaining concerns about doing this?
>
> The only concern I have how this change affects *BSD or prefix? But yet
> I failed to find a package that is affected and that is not Linux
> specific.

Right, there are no plans to touch *bsd. This would just be a
modification to the Linux-specific portion of baselayout.

William


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

William Hubbs
In reply to this post by Richard Yao-2
On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:

> On 10/14/2013 10:11 AM, Rich Freeman wrote:
> > On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <[hidden email]> wrote:
> >> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
> >>
> >> With that said, how does changing things benefit/affect users, especially non-systemd users?
> >
> > Better support for namespaces, for one.
> >
> > If this is actually going to actually break something, by all means
> > speak up.  Otherwise this really comes across as the whole
> > I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
> > /etc/mtab a symlink, and if down the road something doesn't work as a
> > result feel free to fork it unless you can convince somebody else to
> > make it work.  So far the only concrete issues that have been raised
> > seem minor - pertaining to NFS and PAM (both having solutions
> > available).
> >
> > If this causes trouble for the FreeBSD folks I'm interested in what
> > kinds of compromises can be reached.  I think a challenge is that
> > Linux and FreeBSD seem to be very slowly diverging - for software that
> > lives near the kernel/userspace boundary that could make things
> > interesting.  There doesn't seem to be much desire to limit Linux
> > distros to purely POSIX behavior.
As I said earlier in the thread, the planned baselayout change will only
affect Linux.

> My main concern is that some of the configure flags being proposed could
> make packages that worked on Gentoo FreeBSD stop working there. I am not
> making changes, but I think that there should be some benefit and that
> care should be taken not to break things for everyone else.

Richard, the packages we are discussing (nilfs-utils and nfs-utils)
are linux-specific, so there is nothing to worry about on the *bsd side
for them.

> That being said, mgorny said that this adds support for mount
> namespaces, but I have yet to hear an explanation of what that actually
> means. What are the use cases?

There has been a lot written on this; you might want to google
"per-process namespaces".

William


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
In reply to this post by Richard Yao-2
On 10/14/2013 10:46 AM, Richard Yao wrote:
> My main concern is that some of the configure flags being proposed could
> make packages that worked on Gentoo FreeBSD stop working there. I am not
> making changes, but I think that there should be some benefit and that
> care should be taken not to break things for everyone else.
>
> That being said, mgorny said that this adds support for mount
> namespaces, but I have yet to hear an explanation of what that actually
> means. What are the use cases?
>

Someone brought to my attention that there was a slight error in the
above message. I had meant to write "I am not against making changes..."
rather than "I am not making changes...".

In hindsight, the statement that "I am not making changes" was a more
profound statement than the one that I meant to write because it can be
interpreted in any of two ways:

1. It could be interpreted as meaning that I intend to oppose proposed
changes when they have no benefit and I have the ability to oppose them.
2. It could be interpreted as meaning that I am not one of the people
who make decisions for the packages involved. Consequently, my opinion
here only matters to the extent that those who make decisions are
willing to consider it.

Both of which are correct. That being said, I am not against making
changes, but given that this is on the list, I would like to someone to
provide a technical justification. Some key questions that justification
should answer are "what capability does this provide to sysytemd that
cannot be obtained without this change? and "what does that do for
users"? So far, the only thing that I have read is "systemd wants it",
which answers neither question.


signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
In reply to this post by William Hubbs
On 10/14/2013 12:34 PM, William Hubbs wrote:

> On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:
>> On 10/14/2013 10:11 AM, Rich Freeman wrote:
>>> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <[hidden email]> wrote:
>>>> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>>>>
>>>> With that said, how does changing things benefit/affect users, especially non-systemd users?
>>>
>>> Better support for namespaces, for one.
>>>
>>> If this is actually going to actually break something, by all means
>>> speak up.  Otherwise this really comes across as the whole
>>> I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
>>> /etc/mtab a symlink, and if down the road something doesn't work as a
>>> result feel free to fork it unless you can convince somebody else to
>>> make it work.  So far the only concrete issues that have been raised
>>> seem minor - pertaining to NFS and PAM (both having solutions
>>> available).
>>>
>>> If this causes trouble for the FreeBSD folks I'm interested in what
>>> kinds of compromises can be reached.  I think a challenge is that
>>> Linux and FreeBSD seem to be very slowly diverging - for software that
>>> lives near the kernel/userspace boundary that could make things
>>> interesting.  There doesn't seem to be much desire to limit Linux
>>> distros to purely POSIX behavior.
>
> As I said earlier in the thread, the planned baselayout change will only
> affect Linux.
>
>> My main concern is that some of the configure flags being proposed could
>> make packages that worked on Gentoo FreeBSD stop working there. I am not
>> making changes, but I think that there should be some benefit and that
>> care should be taken not to break things for everyone else.
>
> Richard, the packages we are discussing (nilfs-utils and nfs-utils)
> are linux-specific, so there is nothing to worry about on the *bsd side
> for them.
That is good to hear. There were a few situations int he past where
changes were made for Gentoo Linux that broke Gentoo FreeBSD, so I
wanted to be certain that we were not going to have a repeat of that here.

>> That being said, mgorny said that this adds support for mount
>> namespaces, but I have yet to hear an explanation of what that actually
>> means. What are the use cases?
>
> There has been a lot written on this; you might want to google
> "per-process namespaces".

If this merits discussion on the list, then it should merit answers for
these questions:

1. What are mount namespaces? How do they integrate with the kernel?
2. What does systemd do with them? What does systemd's use of them
provide to users?

Saying to google "per-process namespaces" does not really answer that.
Per-process namespaces provide a means to isolate processes into
containers that they have their own pid numbers and can neither nor
interact with processes outside of the container via traditional IPC
mechanisms such as signals. It is similar to the concept of FreeBSD
jails. That does not tell me what a "mount namespace is" or why systemd
has anything to do with it.


signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

William Hubbs
In reply to this post by Richard Yao-2
On Mon, Oct 14, 2013 at 12:47:08PM -0400, Richard Yao wrote:

*snip*

> Both of which are correct. That being said, I am not against making
> changes, but given that this is on the list, I would like to someone to
> provide a technical justification. Some key questions that justification
> should answer are "what capability does this provide to sysytemd that
> cannot be obtained without this change? and "what does that do for
> users"? So far, the only thing that I have read is "systemd wants it",
> which answers neither question.

A quick google for per-process namespaces turns up this lwn series:

http://lwn.net/Articles/531114/

This functionality can't be fully supported if /etc/mtab is a file.

William


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
In reply to this post by Richard Yao-2
On Mon, Oct 14, 2013 at 1:01 PM, Richard Yao <[hidden email]> wrote:

>
> 1. What are mount namespaces? How do they integrate with the kernel?
> 2. What does systemd do with them? What does systemd's use of them
> provide to users?
>
> Saying to google "per-process namespaces" does not really answer that.
> Per-process namespaces provide a means to isolate processes into
> containers that they have their own pid numbers and can neither nor
> interact with processes outside of the container via traditional IPC
> mechanisms such as signals. It is similar to the concept of FreeBSD
> jails. That does not tell me what a "mount namespace is" or why systemd
> has anything to do with it.
>

You're describing a process namespace, which is only one type of
namespace.  All namespaces are "per-process," but process namespaces
are just one type of per-process namespace.  Confused yet?

All processes within the same mount namespace see the same filesystem.
 If I run mount /dev/cdrom /mnt/cdrom in one process, then all
processes in the same namespace will see it mounted.  However,
processes in another namespace will NOT see the new mount.

To illustrate, if you are on linux with util-linux installed launch
two root shells, and in one execute:
mkdir /tmp/foo
touch /tmp/foo/a
unshare -m /bin/bash
mount -t tmpfs none /tmp/foo
touch /tmp/foo/b
ls /tmp/foo

Then run ls /tmp/foo in your other process.  They'll see two different
directories, because the tmpfs mounted in the separate namespace
created by unshare is not visible to any other process.  To clean up
within the namespace umount /tmp/foo and exit (I have no idea if it is
possible to unmount the tmpfs if you exit first, or if the kernel does
it for you).

The possibilities are endless.  You could mount an encrypted home for
a user and make it visible only to the user.  Containers are an
obvious way to use them.

Systemd lets you configure daemons to have restricted access to the
filesystem as well - either read-only, or not at all - by directory.
I assume it just clones the mount namespace, and then sets up
bind-mounts to implement this before dropping root and launching the
process.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

David Leverton-2
In reply to this post by Rich Freeman
Rich Freeman wrote:
> [...] and the point that many things
> break in namespaces without the symlink, since /etc/mtab does not
> reflect the state of the namespace.  The latter in particular seems
> like a pretty fundamental limitation - the very concept of /etc/mtab
> is that mounts are global, and the design of linux is that mounts are
> NOT global.

If only someone would invent some sort of kernel feature that could make
the name "/etc/mtab" refer to different files in different processes....


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
In reply to this post by Rich Freeman
On 10/14/2013 01:24 PM, Rich Freeman wrote:
> Systemd lets you configure daemons to have restricted access to the
> filesystem as well - either read-only, or not at all - by directory.
> I assume it just clones the mount namespace, and then sets up
> bind-mounts to implement this before dropping root and launching the
> process.

On 10/14/2013 01:08 PM, William Hubbs wrote:
> This functionality can't be fully supported if /etc/mtab is a file.

That is all that I needed to read. Make sure that there are no
regressions for existing users and I am all for it. :)


signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
In reply to this post by David Leverton-2
On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
<[hidden email]> wrote:
>
> If only someone would invent some sort of kernel feature that could make the
> name "/etc/mtab" refer to different files in different processes....
>

Well, the symlink seems like the simpler solution to be honest.  I
mean, instead of having the ps command to list running processes you
could just have a daemon dump the list in a file every 10 seconds and
have programs read it, but...

However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes.  Mount namespaces can
only operate at the directory level.

I was actually looking into using namespaces as an alternative to the
sandbox model portage currently uses.  Basically you'd look at a
package's DEPENDs and build a namespace containing only those files,
and now devs don't inadvertently add ebuilds that are missing DEPENDs.

A bit of a tangent, but the sandbox functionality in portage CAN be
used to do just this with somewhat little effort.  I've just never
gotten around to trying it out.  By default sandbox is told to give
read-access to everything - the sandbox command does restrict both
reads and writes already and if that configuration were made dynamic
and set by portage per-package it would work just fine.  I just
figured namespaces would be a more elegant solution (it is also more
secure, but security isn't really a concern here).

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

David Leverton-2
Rich Freeman wrote:
> However, FWIW, linux namespaces cannot be used to have only a single
> file appear differently to different processes.  Mount namespaces can
> only operate at the directory level.

So to work around that limitation we insist that everyone change how
their systems are set up, and still have to reintroduce mtab under a
different name ("utab", hidden away under /run) because
/proc/self/mounts *doesn't* contain everything that's supposed to be in
mtab after all?

If someone decides they want to use, say, different DNS servers in
different namespaces, should we make the kernel store the server IP
addresses, add a /proc file that dumps them out in the expected format,
and demand that everyone replace their /etc/resolv.conf with a symlink
to /proc/self/resolv.conf?  Or maybe, if people want namespaces, they
can implement them properly, in which case it becomes literally a
self-solving problem.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Mike Gilbert-2
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
<[hidden email]> wrote:

> Rich Freeman wrote:
>>
>> However, FWIW, linux namespaces cannot be used to have only a single
>> file appear differently to different processes.  Mount namespaces can
>> only operate at the directory level.
>
>
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?
>
> If someone decides they want to use, say, different DNS servers in different
> namespaces, should we make the kernel store the server IP addresses, add a
> /proc file that dumps them out in the expected format, and demand that
> everyone replace their /etc/resolv.conf with a symlink to
> /proc/self/resolv.conf?  Or maybe, if people want namespaces, they can
> implement them properly, in which case it becomes literally a self-solving
> problem.
>
>

This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
In reply to this post by David Leverton-2
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
<[hidden email]> wrote:
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?

The whole design of /etc/mtab is broken.  It isn't a list of
everything that is mounted - it is a list of everything done by the
mount command (the command - not the system call).  The handbook even
has a line about having to manually populate it before running grub
since it is flat-out wrong when you're in a chroot.  There are lots of
things that can cause it to get out-of-sync.

Perhaps there are edge cases where the symlink isn't sufficient -
that's what this thread is all about.  However, I've never liked the
design of mtab.  It isn't surprising to me that distros are largely
ditching it.

>  /etc/resolv.conf

As Mike already pointed out, resolution is actually a userspace
function entirely (I'm not sure if I were designing things from
scratch that I'd put it in the C library, but...).

However, if you want to know the hostname, you should be calling uname
and not looking around for /etc/hostname or whatever.  The kernel will
tell you the truth as it applies to your process, not what you think
should be the truth based on what amounts to a logfile.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

David Leverton-2
In reply to this post by Mike Gilbert-2
Mike Gilbert wrote:
> This is a horrible example. /etc/resolv.conf is a configuration file
> for code that lives entirely in userspace. Of course it makes no sense
> to shove that into the kernel.

My point is that it's silly to have a hard-coded special case in the
kernel for mtab, especially if it doesn't do the job properly and
requires an extra utab file, when the general solution could work for
any file and wouldn't require any changes when the namespace feature
isn't in use.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Patrick McLean-3
In reply to this post by Rich Freeman
On Mon, 14 Oct 2013 15:50:36 -0400
Rich Freeman <[hidden email]> wrote:

> On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
> <[hidden email]> wrote:
> >
> > If only someone would invent some sort of kernel feature that could
> > make the name "/etc/mtab" refer to different files in different
> > processes....
> >
>
> However, FWIW, linux namespaces cannot be used to have only a single
> file appear differently to different processes.  Mount namespaces can
> only operate at the directory level.

This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

David Leverton-2
Patrick McLean wrote:
> This is not true. Bind mounts can be performed on a single file, and
> bind mounts are part of mount namespaces. Granted the target file _must_
> exist (it could be a dead symlink, or a symlink to /dev/null) before
> performing the bind mount.

Well that's even better then. :-)


Reply | Threaded
Open this post in threaded view
|

rfc: read-only root Was: rfc: converting /etc/mtab to a symlink

Duncan-42
In reply to this post by William Hubbs
William Hubbs posted on Sun, 13 Oct 2013 14:32:32 -0500 as excerpted:

> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

New subthread here as I don't see this mentioned in the others (tho pacho
mentions it in the bug) ...

TL;DR: An /etc/mtab symlink is the generally recommended and simplest way
to make a read-only root work, and I've been setup like that for some
months now, so I'm all for it. =:^)

Some months ago I finally upgraded my core system to SSDs, and with that,
btrfs (I had been on reiserfs for years with very good results even thru
hardware issues as since ordered-by-default journaling went in, anyway,
it's an incredibly stable filesystem that doesn't have the kernel folks
monkeying around with it and trying stuff like the infamous ext3-
writeback-by-default tricks, like the ext* filesystems do, but
unfortunately reiserfs simply was no designed for nor is it suited to
SSDs), which of course is still an experimental filesystem, for good
reason as altho the mainstream case tends to work relatively well,
they're still fixing critical corner-case bugs with every kernel release.

So to hopefully counter some of the additional risk, and because I had
been looking at the idea for a couple years anyway, I setup a read-only
root by default.  And I'll tell you what, it sure is nice knowing that
after a hard shutdown and reboot, while /home and /var/log will probably
have integrity errors due to the bad shutdown and I'll need to do a btrfs
scrub to repair them (a pair of SSDs with most filesystems in btrfs raid1
mode for both data and metadata, so there's the second copy of all
(meta)data to read and restore from if the first is corrupt and fails the
integrity check), root itself should be safe, since it was mounted read-
only and thus no ongoing writes could have been occurring there when the
crash occurred.  And of course the btrfs recovery tools are on root, so
if worse did come to worse, they should be fine to use in recovering
/home, since the root filesystem was read-only the entire period and thus
should be undamaged. =;^)

Of course in ordered to setup a read-only root, I had to make some
changes, including the one under discussion here, making /etc/mtab a
symlink to /proc/self/mounts.  (Actually, I symlinked it to /proc/mounts,
but as mentioned elsewhere in the thread, on a modern kernel since mount
namespaces, that's a symlink to /proc/self/mounts already, so same
ultimate result.)

So I'm all for the change, since that will bring the default gentoo
installation one step closer to a read-only root, meaning one less thing
for people who want to setup that way to have to worry about. =:^)

Meanwhile, the handbook has for years suggested a separate /boot and
mentioned the separate /home option.  Once we have /etc/mtab as a
symlink, the next logical step would be to consider upgrading that
separate /home option to suggested default, adding /var/log as a
suggested default, and making the default fstab options for / include ro,
thus increasing default gentoo system data robustness dramatically.  Of
course the system-updates/portage discussion would then need a reminder
to remount / rw, but with /etc/mtab a symlink, further necessary changes
are minor, and it really will improve gentoo system robustness
dramatically, likely saving a number of users the headache of having to
recover a screwed up root, simply because it was mounted writable and
didn't happen to be in a consistent state when the system crashed.

(Arguably that should be a (sub-)thread of its own, thus the retitled
subthread, already top-level.)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


12