Let's redesign the entire filesystem!
 

On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers <quantumsummers@gentoo.org> wrote:

> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).

I happen to understand you're not attempting to start a flame war here,
but it may not obvious to everyone.


jer (no initrds)

Let's redesign the entire filesystem!
 

On 14 March 2012 18:56, Zac Medico <zmedico@gentoo.org> wrote:
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

I wonder if it might help to go through the benefits of having a
separate /usr, and see whether they still work when /usr is mounted by
initramfs. Hopefully that would either demonstrate that the initramfs
approach is fine, or reveal a concrete problem with it so we can start
talking about solutions.

(For the record, I don't have a separate /usr, but mainly because when
I've been setting up machines I've been too lazy to either 1) figure
out how much space to allocate to each partition, or 2) learn how to
use lvm so I don't have to worry so much about getting it right the
first time. I'd prefer for the option to stay available, but not as
strongly as some people do.)

To start us off, the benefit that I'm mainly interested in (for
potential future use, as stated above), and I realise this is probably
pretty far down the list overall, is that OpenRC can run fsck at
shutdown instead of boot for non-/ filesystems, so as long as / is
small there won't be huge boot delays. I imagine using initramfs
wouldn't affect this, as by the time the system's shutting down it
shouldn't matter how /usr got mounted originally. It might be
affected if fsck etc got moved to /usr as has been mentioned, but if
that happened OpenRC would probably have to be modified to remount it
readonly at shutdown rather than unmount it, and presumably that would
allow the fsck to occur.

Would anyone else like to continue with their own favourite
separate-/usr reason?

Let's redesign the entire filesystem!
 

On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> <quantumsummers@gentoo.org> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> etc.
>>
>> There is nothing bad about initramfs. I think that you are misreading
>> the arguments above.
>
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

I do not have a separate /usr partition, however I agree with Joshua
Kinard's stance regarding the /usr move. The point of having a separate
/usr was to enable UNIX to exceed the space constraints that a 1.5MB
hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
rootfs so it would make sense to deprecate the practice of having things
that belong in / in /usr directory, as opposed to making /usr into a new /.

Deprecation of this practice would mean that people could type
/bin/command instead of /usr/bin/command in situations where absolute
paths are necessary. We could symlink things in /usr to rootfs for
compatibility with legacy software. In a more extreme case, we could
symlink /usr to /, which would make plenty of sense given that we do not
need a separate /usr at all.

Let's redesign the entire filesystem!
 

On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote
> On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> > 120314 Greg KH wrote:
> > > if you have /usr on a different filesystem today, with no initrd,
> > > your machine could be broken and you don't even know it.
> >
> > Whatever do you mean ? -- if it were truly broken,
> > it wouldn't perform in some important & obvious respect.
>
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly. Some programs later
> on recover and handle things better.

Throwing that one right back at you, if you have /usr on the same file
system, plus you boot with systemd, your machine could be broken and you
don't even know it.

--
Walter Dnes <waltdnes@waltdnes.org>

Let's redesign the entire filesystem!
 

On 03/14/2012 01:03 PM, Richard Yao wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> <quantumsummers@gentoo.org> wrote:
>>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>>> etc.
>>>
>>> There is nothing bad about initramfs. I think that you are misreading
>>> the arguments above.
>>
>> Whatever the arguments may be, the whole discussion boils down to the
>> fact that the only people who seem to have a "problem" are those that
>> have a separate /usr partition and simultaneously refuse to use an
>> initramfs.
>
> I do not have a separate /usr partition, however I agree with Joshua
> Kinard's stance regarding the /usr move. The point of having a separate
> /usr was to enable UNIX to exceed the space constraints that a 1.5MB
> hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
> rootfs so it would make sense to deprecate the practice of having things
> that belong in / in /usr directory, as opposed to making /usr into a new /.
>
> Deprecation of this practice would mean that people could type
> /bin/command instead of /usr/bin/command in situations where absolute
> paths are necessary. We could symlink things in /usr to rootfs for
> compatibility with legacy software. In a more extreme case, we could
> symlink /usr to /, which would make plenty of sense given that we do not
> need a separate /usr at all.

I'm not seeing any compelling benefits here that would justify a lack of
conformity with other *nix distros. It seems almost as though it's an
attempt to be different for the sake of being different, perhaps a
symptom of something like NIH syndrome.
--
Thanks,
Zac

Let's redesign the entire filesystem!
 

On Wed, Mar 14, 2012 at 03:59:56PM +0000, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:22:09 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> > The people doing the work today do understand them, by virtue of
> > doing the work involved, which gives them the say in how it is done.
> > That's how open source works, why is this ever a surprise to people?
>
> The problem is that when a small number of people who have commit
> access to core projects screw everything up and don't fix the mess
> they're inflicting upon everyone,

Again, there is a simple solution for this problem, already provided,
and supported, so no "mess" talking here please, that's just trying to
be dramatic.

> the only option left with "how open source works" is for someone to
> fork the code from the point where it all worked. That isn't something
> that should be done lightly.

Forking should ALWAYS be done lightly and often, I highly recommend it.

If you think you know how to do something better, it's best to fork,
work it out, and if you come up with something, then work to merge it
back, if at all possible. If merging doesn't work, and it turns out
that your stuff works better, people will migrate to it, keeping it
alive.

Odds are, the fork will turn out to be a dead-end, and it will die off.
But you will then know the reasons why, and not be so upset when others
do things you disagree with.

That's the way evolution works, and it works quite well, it's why open
soure works as well as it does.

So please, fork away, I can't recommend it enough. Remember, it's what
got us Gentoo :)

greg k-h

Let's redesign the entire filesystem!
 

On Wed, Mar 14, 2012 at 07:57:52PM +0000, David Leverton wrote:
> Would anyone else like to continue with their own favourite
> separate-/usr reason?

Haveing a separate /usr is wonderful, and once we finish moving /sbin/
and /bin/ into /usr/ it makes even more sense. See the /usr page at
fedora for all of the great reasons why this is good.

What doesn't make sense is people who do that, refusing to use an initrd
or initramfs to make the whole thing work properly.

It's as if people want the benefits, yet fail to want to actually use
the tools required to get those benefits. It makes no sense, and if
anyone continues to complain, it shows a lack of understanding.

greg k-h

Let's redesign the entire filesystem!
 

On 03/14/12 16:55, Zac Medico wrote:
> On 03/14/2012 01:03 PM, Richard Yao wrote:
>> I do not have a separate /usr partition, however I agree with Joshua
>> Kinard's stance regarding the /usr move. The point of having a separate
>> /usr was to enable UNIX to exceed the space constraints that a 1.5MB
>> hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
>> rootfs so it would make sense to deprecate the practice of having things
>> that belong in / in /usr directory, as opposed to making /usr into a new /.
>>
>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more extreme case, we could
>> symlink /usr to /, which would make plenty of sense given that we do not
>> need a separate /usr at all.
>
> I'm not seeing any compelling benefits here that would justify a lack of
> conformity with other *nix distros. It seems almost as though it's an
> attempt to be different for the sake of being different, perhaps a
> symptom of something like NIH syndrome.

How did RedHat justify that lack of conformity that resulted from moving
everything into /usr in the first place? The original UNIX did not have
anything in /usr. The /usr split was caused by Bell Labs having to grow
UNIX past the constraints of a 1.5MB hard drive. Since we are no longer
limited by such space constraints, I fail to see why we should not
deprecate /usr.

In the meantime, it should be possible to create a global usr USE flag
that enables/disables gen_usr_ldscript. It would then be possible to
delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
The dynamic linker would go to / before /usr and it would be trivial to
modify $PATH to ignore /usr entirely. Legacy software that requires
/usr/{bin,sbin} would still work while those that want a separate /usr
mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
counterparts.

Let's redesign the entire filesystem!
 

On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense. *See the /usr page at
> fedora for all of the great reasons why this is good.

My point was examine, in detail, whether separate-/usr-with-initramfs
has any disadvantages compared to separate-/usr-without-initramfs.
Either it has, in which case we have a concrete argument against
requiring initramfs (albeit possibly one that can be fixed), or it
hasn't, which should hopefully convince at least some people to accept
it.

Let's redesign the entire filesystem!
 

On 03/14/12 17:04, Greg KH wrote:
> On Wed, Mar 14, 2012 at 07:57:52PM +0000, David Leverton wrote:
>> Would anyone else like to continue with their own favourite
>> separate-/usr reason?
>
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense. See the /usr page at
> fedora for all of the great reasons why this is good.
>
> What doesn't make sense is people who do that, refusing to use an initrd
> or initramfs to make the whole thing work properly.
>
> It's as if people want the benefits, yet fail to want to actually use
> the tools required to get those benefits. It makes no sense, and if
> anyone continues to complain, it shows a lack of understanding.
>
> greg k-h
>

Is this that page?

http://fedoraproject.org/wiki/Features/UsrMove

That refers to the systemd website on freedesktop.org.

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Reading that, it seems to me that this /usr move was caused by a
systemd-specific decision that rootfs should be both system-specific and
located on the particular system while /usr should be network mountable.
However, I see no argument for why that should be the case.

Thinking about it, I suppose this would make sense in an enterprise
setting where everything is diskless. If you PXE boot, put rootfs on
iSCSI and have /usr on a NFS mount, this would work very well. Claiming
that people show a lack of understanding when you never explain this,
however, is definitely the wrong thing to do.

With that said, I have a few questions:

1. Why does no one mention the enterprise use case at all?
2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
3. Why not let the users choose where these directories go and support
both locations?