Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

 

 

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


mk at dee

Mar 14, 2012, 10:11 AM

Post #26 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 17:22, Greg KH <gregkh [at] gentoo> wrote:
> As for "fixing this", see the oft-linked webpage as to why it can't be
> fixed easily, if at all, and honestly, I don't think it needs to be
> fixed.

What's wrong with:
* having an "early mounts" list file
* having an "early modules" list file
* init system in early boot (e.g., OpenRC in init.sh) loading "early
modules" and mounting "early mounts" from /etc/fstab

This will solve the issue with most non-complex (i.e., no raid or
encryption) initramfs-less setups, without requiring that users
migrate to initramfs (e.g., after dealing with genkernel-generated
scripts for a long time, I wouldn't touch it with a pointed stick
anymore). The relevant files can be also generated automatically
during an upgrade (empty "early modules" and empty or /usr-only "early
mounts", depending on /etc/fstab contents).

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)


zmedico at gentoo

Mar 14, 2012, 10:29 AM

Post #27 of 108 (273 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
> What's wrong with:
> * having an "early mounts" list file
> * having an "early modules" list file
> * init system in early boot (e.g., OpenRC in init.sh) loading "early
> modules" and mounting "early mounts" from /etc/fstab

You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
Other that that, it sounds like a perfect solution if you're in the "I'd
rather die than use an initramfs" camp.
--
Thanks,
Zac


zmedico at gentoo

Mar 14, 2012, 10:52 AM

Post #28 of 108 (271 views)
Permalink
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] [In reply to]

On 03/14/2012 05:00 AM, James Cloos wrote:
>>>>>> "MS" == Marc Schiffbauer <mschiff [at] gentoo> writes:
>
> MS> IIRC usr = unified system resources (not an abbrev. for "user")
>
> Nope. It is in fact for user.
>
> Before sysv created /home, bsd used /usr for user dirs.
>
> /usr/bin et all came later.

Anyway, "unified system resources" makes a great retro-active acronym,
don't you think? What's in a name?
--
Thanks,
Zac


quantumsummers at gentoo

Mar 14, 2012, 10:58 AM

Post #29 of 108 (272 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 12:29 PM, Zac Medico <zmedico [at] gentoo> wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>>   * having an "early mounts" list file
>>   * having an "early modules" list file
>>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mounting "early mounts" from /etc/fstab
>
> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
> Other that that, it sounds like a perfect solution if you're in the "I'd
> rather die than use an initramfs" camp.
> --
> Thanks,
> Zac
>

__Everyone__ is already using an initramfs, therefore there are no
initramfs-less systems anymore (it may just be empty). Every single
person reading this thread that has not already done so needs to
immediately go read the relevant documentation located in
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt,
then and only then can a real discourse be had.

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.

:/

--
Matthew W. Summers
Gentoo Foundation Inc.


rich0 at gentoo

Mar 14, 2012, 10:59 AM

Post #30 of 108 (270 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico <zmedico [at] gentoo> wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>>   * having an "early mounts" list file
>>   * having an "early modules" list file
>>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mounting "early mounts" from /etc/fstab
>
> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
> Other that that, it sounds like a perfect solution if you're in the "I'd
> rather die than use an initramfs" camp.

Well, anybody is welcome to create any replacement/addition for
(/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
good enough, perhaps others will even use it.

Beyond that, anything else is just a suggestion. In the end the folks
writing udev and systemd are writing code, which gets them a lot
further than emails do... :)

Rich


ciaran.mccreesh at googlemail

Mar 14, 2012, 11:04 AM

Post #31 of 108 (272 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers <quantumsummers [at] gentoo> 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.

Because the initramfs is just replacing what / used to be, and it's
even less well handled than "stuff not in /usr" is just now. All using
an initramfs does is move the dependencies problem from somewhere where
we have a solution that used to work and that still mostly works to
somewhere where we don't have anything at all.

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


mk at dee

Mar 14, 2012, 11:36 AM

Post #32 of 108 (270 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 19:58, Matthew Summers
<quantumsummers [at] gentoo> wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).

I suggest that you take a look at CONFIG_BLK_DEV_INITRD.

> 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.

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)


1i5t5.duncan at cox

Mar 14, 2012, 11:48 AM

Post #33 of 108 (274 views)
Permalink
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] [In reply to]

Zac Medico posted on Wed, 14 Mar 2012 10:52:48 -0700 as excerpted:

> On 03/14/2012 05:00 AM, James Cloos wrote:
>>>>>>> "MS" == Marc Schiffbauer <mschiff [at] gentoo> writes:
>>
>> MS> IIRC usr = unified system resources (not an abbrev. for "user")

>> Before sysv created /home, bsd used /usr for user dirs.

> Anyway, "unified system resources" makes a great retro-active acronym,
> don't you think? What's in a name?

It does, especially when it's literally the case, including a /usr/etc
bind-mounted on a tmpfs-based rootfs, that by login time, all that's
visible of rootfs is mountpoints, nothing else, and /usr literally IS the
"unified system resource" filesystem.

--
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


zmedico at gentoo

Mar 14, 2012, 11:56 AM

Post #34 of 108 (271 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
> <quantumsummers [at] gentoo> 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.
--
Thanks,
Zac


michael at orlitzky

Mar 14, 2012, 12:14 PM

Post #35 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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 [at] gentoo> 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.

People just don't like change for the sake of change, and haven't been
shown any benefits yet. I don't have a separate /usr anywhere, but if I
did, I would have to rebuild and test a good number of custom kernels
that would eventually need to wind up on production servers.

It would take a least a day's worth of work, not to mention staying late
to make the switch overnight. If you can offer me something cool for it,
great; but at the moment people are being offered "it will work the same
as it did yesterday," which sucks, because it works that way now.

Sure, there will be improvements in the future, but it can feel a lot
like treading water sometimes.


zmedico at gentoo

Mar 14, 2012, 12:26 PM

Post #36 of 108 (267 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 12:14 PM, Michael Orlitzky 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 [at] gentoo> 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.
>
> People just don't like change for the sake of change, and haven't been
> shown any benefits yet. I don't have a separate /usr anywhere, but if I
> did, I would have to rebuild and test a good number of custom kernels
> that would eventually need to wind up on production servers.
>
> It would take a least a day's worth of work, not to mention staying late
> to make the switch overnight. If you can offer me something cool for it,
> great; but at the moment people are being offered "it will work the same
> as it did yesterday," which sucks, because it works that way now.
>
> Sure, there will be improvements in the future, but it can feel a lot
> like treading water sometimes.

Well, for most people, the most practical course of action is to suck it
up [1] and move on. Dwelling on it certainly won't help, and the
"redesign the entire filesystem" approach probably isn't very practical
for most people either.

[1] http://en.wiktionary.org/wiki/suck_it_up
--
Thanks,
Zac


jer at gentoo

Mar 14, 2012, 12:30 PM

Post #37 of 108 (271 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers <quantumsummers [at] gentoo> 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)


levertond at googlemail

Mar 14, 2012, 12:57 PM

Post #38 of 108 (270 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 14 March 2012 18:56, Zac Medico <zmedico [at] gentoo> 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?


ryao at cs

Mar 14, 2012, 1:03 PM

Post #39 of 108 (268 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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 [at] gentoo> 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.
Attachments: signature.asc (0.88 KB)


kentfredric at gmail

Mar 14, 2012, 1:10 PM

Post #40 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] [In reply to]

On 15 March 2012 07:48, Duncan <1i5t5.duncan [at] cox> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system resource" filesystem.

Considering this pretty much eliminates using / for anything useful,
we might as well rename "/usr" "/c"

Even if it /is/ just to confuse the windows crowd =)


--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"


waltdnes at waltdnes

Mar 14, 2012, 1:12 PM

Post #41 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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 [at] waltdnes>


zmedico at gentoo

Mar 14, 2012, 1:55 PM

Post #42 of 108 (270 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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 [at] gentoo> 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


gregkh at gentoo

Mar 14, 2012, 2:00 PM

Post #43 of 108 (275 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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 [at] gentoo> 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


gregkh at gentoo

Mar 14, 2012, 2:04 PM

Post #44 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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


ryao at cs

Mar 14, 2012, 2:05 PM

Post #45 of 108 (267 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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.
Attachments: signature.asc (0.88 KB)


levertond at googlemail

Mar 14, 2012, 3:14 PM

Post #46 of 108 (271 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 14 March 2012 21:04, Greg KH <gregkh [at] gentoo> 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.


ryao at cs

Mar 14, 2012, 3:39 PM

Post #47 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

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?
Attachments: signature.asc (0.88 KB)


gregkh at gentoo

Mar 14, 2012, 3:49 PM

Post #48 of 108 (273 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
> 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

Yes.

> With that said, I have a few questions:
>
> 1. Why does no one mention the enterprise use case at all?

It has been pointed out before, why constantly repeat ourselves.

> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?

unionfs is still a "work in progress", some systems can't do that yet.

> 3. Why not let the users choose where these directories go and support
> both locations?

Because a plethera of options is a sure way to make sure that half of
them don't work over the long run.

We aren't Debian here people, we don't support "everything" :)

If you want to support both, great, feel free to step up and do the
work.

greg k-h


gregkh at gentoo

Mar 14, 2012, 3:51 PM

Post #49 of 108 (271 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 10:14:54PM +0000, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH <gregkh [at] gentoo> 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.

Oh, that's simple, separate-/usr-without-initramfs will not work and
will not be supported :)

Again, the fact that it works for some people today is pure luck, and
odds are, it really isn't, but it's really hard to determine this given
that the init system they are using doesn't provide a good feedback loop
for this type of thing.

Hence, it is not supported.

thanks,

greg k-h


levertond at googlemail

Mar 14, 2012, 4:21 PM

Post #50 of 108 (269 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 14 March 2012 22:51, Greg KH <gregkh [at] gentoo> wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)

See, it's this "we're doing it this way because we know best and we
say so" that upsets people. I'm trying to encourage everyone to get
to the core reasons for having a separate /usr in the first place (not
all of which are guaranteed to be mentioned on any specific wiki
page), and logically analyse the potential disadvantages of using an
initramfs in each situation. It may turn out that there are no
disadvantages after all, but the analysis is still important, not only
to make sure that "we"'re making the right decision, but also to
persuade everyone else that it's the right decision.

> Again, the fact that it works for some people today is pure luck, and
> odds are, it really isn't, but it's really hard to determine this given
> that the init system they are using doesn't provide a good feedback loop
> for this type of thing.

Maybe it would be worth improving the init system to do so? Or maybe
it wouldn't because using an initramfs is easier and has no drawbacks,
but see above.

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.