FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-12-2011, 04:09 AM
Ivan Shmakov
 
Default / vs. /usr vs. fsck(8)

>>>>> Marco d'Itri <md@Linux.IT> writes:

[…]

> So let's look at the reasons against merging /usr in / listed in my
> final summary. All of them do not apply to merging / in /usr, and
> actually become arguments in favour of doing it:

> - NFS: sharing a read only system over NFS becomes much easier (I
> would say that it actually becomes possible...)

Agreed. Being one who actually have experimented with such a
setup, I'd say that it makes an NFS boot environment much easier
to maintain.

[…]

However, please note that the current state of affairs (AIUI) is
that we rely on / to check all the other filesystems before
these are mounted. If the / filesystem is itself modified in
the process, we're to reboot the system for safety.

With /usr being mounted by initramfs, either we'd need to allow
/usr to be checked /after/ it's mounted (by the filesystem
checkers residing on it, which doesn't seems all that sane),
/or/ we'd need to put all the filesystem checkers to initramfs.
This implies that the latter would've to be updated each time a
new filesystem check program is added to (and, perhaps, removed
from) the system.

[…]

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86k48a26n7.fsf_-_@gray.siamics.net">http://lists.debian.org/86k48a26n7.fsf_-_@gray.siamics.net
 
Old 10-12-2011, 06:40 AM
Reinhard Tartler
 
Default / vs. /usr vs. fsck(8)

On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote:

>>>>>> Marco d'Itri <md@Linux.IT> writes:
>
> […]
>
> > So let's look at the reasons against merging /usr in / listed in my
> > final summary. All of them do not apply to merging / in /usr, and
> > actually become arguments in favour of doing it:
>
> > - NFS: sharing a read only system over NFS becomes much easier (I
> > would say that it actually becomes possible...)
>
> Agreed. Being one who actually have experimented with such a
> setup, I'd say that it makes an NFS boot environment much easier
> to maintain.
>
> […]
>
> However, please note that the current state of affairs (AIUI) is
> that we rely on / to check all the other filesystems before
> these are mounted. If the / filesystem is itself modified in
> the process, we're to reboot the system for safety.
>
> With /usr being mounted by initramfs, either we'd need to allow
> /usr to be checked /after/ it's mounted (by the filesystem
> checkers residing on it, which doesn't seems all that sane),
> /or/ we'd need to put all the filesystem checkers to initramfs.

AFAIUI Harald (the fedora maintainer for their initramfs tool dracut), he
dislikes having a separate set of tools in /usr and the initramfs, i.e.,
he strongly favors putting glibc, bash, iproute and similar utilities
directly in the initramfs. The main motivation (again AFAIUI) seems to be
behavioral consistency of tools between early userspace and the booted
system.

On the other hand, Debian has chosen against that and relies on klibc,
ipconfig, etc. for early userspace and thus, the initramfs. I suspect
the main motivations behind these decisions were portability and size
(please correct me and add references).

I imagine it would be pretty challenging to improve the klibc based
tools to become feature-par and sufficiently behaviorally consistent
with their glibc based equivalents. In any case, I think having this in
mind is relevant for deciding whether the various fsck(8) utilities can
or should go into the initramfs or not.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87botmaf18.fsf@faui43f.informatik.uni-erlangen.de">http://lists.debian.org/87botmaf18.fsf@faui43f.informatik.uni-erlangen.de
 
Old 10-12-2011, 08:33 AM
Ivan Shmakov
 
Default / vs. /usr vs. fsck(8)

>>>>> Reinhard Tartler <siretart@debian.org> writes:
>>>>> On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote:

[…]

> AFAIUI Harald (the fedora maintainer for their initramfs tool
> dracut), he dislikes having a separate set of tools in /usr and the
> initramfs, i.e., he strongly favors putting glibc, bash, iproute and
> similar utilities directly in the initramfs. The main motivation
> (again AFAIUI) seems to be behavioral consistency of tools between
> early userspace and the booted system.

Well, in the light of this, the original proposal now makes some
sense. Indeed, they've made their initramfs their new /, and
now wonder why would they need two /? Quite a sensible
question, as it seems. Still, I don't think that it's
applicable at all to Debian.

> On the other hand, Debian has chosen against that and relies on
> klibc, ipconfig, etc. for early userspace and thus, the initramfs. I
> suspect the main motivations behind these decisions were portability
> and size (please correct me and add references).

If anything, I'd vote for the Debian way.

And, I guess that makes Debian's initramfs and the system itself
less interdependent, to the point that one could boot a system
with a (kernel, initramfs) combination that's several revisions
behind (or ahead) of the system proper.

> I imagine it would be pretty challenging to improve the klibc based
> tools to become feature-par and sufficiently behaviorally consistent
> with their glibc based equivalents. In any case, I think having this
> in mind is relevant for deciding whether the various fsck(8)
> utilities can or should go into the initramfs or not.

I believe that should fsck(8) be moved to initramfs, there would
essentially be no reason to keep the rest of the «big stuff» off
the latter.

[…]

--
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86y5wqzk1i.fsf@gray.siamics.net">http://lists.debian.org/86y5wqzk1i.fsf@gray.siamics.net
 
Old 10-12-2011, 07:24 PM
 
Default / vs. /usr vs. fsck(8)

On Oct 12, Reinhard Tartler <siretart@debian.org> wrote:

> On the other hand, Debian has chosen against that and relies on klibc,
> ipconfig, etc. for early userspace and thus, the initramfs. I suspect
> the main motivations behind these decisions were portability and size
> (please correct me and add references).
The Debian initramfs of my sid system is 10 MB, while the one from my
RHEL 6.1 servers is 12 MB. So there is no big difference here.
I still do not believe that portability is an issue, and please remember
that this would not force people to use an initramfs unless they want to
keep /usr on a standalone file system.

SuSE has been doing fsck in the initramfs for ages, probably Red Hat
will do the same.

--
ciao,
Marco
 
Old 10-12-2011, 08:20 PM
Stephan Seitz
 
Default / vs. /usr vs. fsck(8)

On Wed, Oct 12, 2011 at 09:24:33PM +0200, Marco d'Itri wrote:

The Debian initramfs of my sid system is 10 MB, while the one from my


My / (testing) is 193M, so I guess, I have much more „emergency” programs
available than you. The last time I was trapped within a initramfs, the
available programs were useless for me, so I booted with a Knoppix DVD.


Getting all the programs in the initramfs would probably make it bigger
than my /boot.


Beside the initramfs is not a normal partition you can mount with
a rescue DVD. So a broken initramfs is harder to fix.


I don’t see any advantage in mixing / and /usr.


I still do not believe that portability is an issue, and please remember
that this would not force people to use an initramfs unless they want to
keep /usr on a standalone file system.


Most of my systems don’t use initramfs and have / and /usr on different
file systems. I am no interested in changing this good tradition.

So please don’t break other people’s setup.

Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: stse@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
 
Old 10-12-2011, 10:31 PM
Michelle Konzack
 
Default / vs. /usr vs. fsck(8)

Hello Stephan Seitz,

Am 2011-10-12 22:20:50, hacktest Du folgendes herunter:
> Most of my systems don’t use initramfs and have / and /usr on
> different file systems. I am no interested in changing this good
> tradition.

Here too...
Using the inittamfs on my 6 storage servers (each 48 HDD 2 TB intern and
the same extern)requires "rootdelay=3000" and longer. Working without
reduce the average boottime to 12 minutes.

> So please don’t break other people’s setup.

1+

> Shade and sweet water!
> Stephan

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/
 
Old 10-12-2011, 10:49 PM
 
Default / vs. /usr vs. fsck(8)

On Oct 13, Michelle Konzack <linux4michelle@tamay-dogan.net> wrote:

> Using the inittamfs on my 6 storage servers (each 48 HDD 2 TB intern and
> the same extern)requires "rootdelay=3000" and longer. Working without
> reduce the average boottime to 12 minutes.
Looks like you need to work out what is going wrong with the initramfs
then.

--
ciao,
Marco
 
Old 10-13-2011, 03:22 AM
Josh Triplett
 
Default / vs. /usr vs. fsck(8)

Stephan Seitz wrote:
> On Wed, Oct 12, 2011 at 09:24:33PM +0200, Marco d'Itri wrote:
>> I still do not believe that portability is an issue, and please
>> remember that this would not force people to use an initramfs unless
>> they want to keep /usr on a standalone file system.
>
> Most of my systems don’t use initramfs and have / and /usr on
> different file systems. I am no interested in changing this good
> tradition.

Other than tradition, for what reason do you put /usr on a different
filesystem?

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013032207.GA3832@leaf">http://lists.debian.org/20111013032207.GA3832@leaf
 
Old 10-13-2011, 07:47 AM
Stephan Seitz
 
Default / vs. /usr vs. fsck(8)

On Wed, Oct 12, 2011 at 08:22:09PM -0700, Josh Triplett wrote:

Other than tradition, for what reason do you put /usr on a different
filesystem?


- I think that the probability that defective hard drive sectors will hit
a small partition is less. So your „repair partition” will probably
boot at least in emergency mode with more tools than any initramfs.

I think that small file systems are less error-prone as well.
- Rescue DVDs may not support modern file systems because of older
kernels. Here /usr was reiserfs for years, then switched to ext3, new
systems have ext4 now. But / was ext2 for a long time (good enough for
small partitions), now it has ext3. So it can always be repaired with
a rescue DVD.


So I am not really interested in making the important boot/repair
partition bigger than necessary.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: stse@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |
 
Old 10-13-2011, 09:19 AM
Luca Capello
 
Default / vs. /usr vs. fsck(8)

Hi there!

On Wed, 12 Oct 2011 21:24:33 +0200, Marco d'Itri wrote:
> On Oct 12, Reinhard Tartler <siretart@debian.org> wrote:
>
>> On the other hand, Debian has chosen against that and relies on klibc,
>> ipconfig, etc. for early userspace and thus, the initramfs. I suspect
>> the main motivations behind these decisions were portability and size
>> (please correct me and add references).
> The Debian initramfs of my sid system is 10 MB, while the one from my
> RHEL 6.1 servers is 12 MB. So there is no big difference here.

I checked my systems and found out something strange about initrd sizes,
all with MODULES=most in /etc/initramfs-tools/initramfs.conf:

|--------------+------------------+-------------|
| distribution | kernel | initrd size |
|--------------+------------------+-------------|
| lenny | 2.6.26-2-orion5x | 3287928 |
| | 2.6.26-2-amd64 | 7766596 |
| | 2.6.26-2-amd64 | 7787529 |
| | 2.6.26-1-686 | 7626120 |
| | 2.6.26-2-686 | 7629923 |
| | 2.6.26-2-686 | 7635738 |
| squeeze | 2.6.32-5-amd64 | 9245071 |
| | 2.6.32-5-amd64 | 9256338 |
| | 2.6.32-5-amd64 | 9260727 |
| | 2.6.32-5-amd64 | 9919173 |
| | 2.6.32-5-amd64 | 10506190 |
| | 2.6.32-5-686 | 10509240 |
| | 2.6.39-2-amd64 | 10680155 |
| | 3.0.0-1-amd64 | 10858550 |
| sid | 3.0.0-2-amd64 | 4057637 |
| | 3.1.0-rc4-amd64 | 4120746 |
| | 3.1.0-rc7-amd64 | 4121794 |
|--------------+------------------+-------------|

On my sid, using MODULES=dep I get 4062599 for 3.1.0-rc7-amd64, which is
practically no different from MODULES=most. Considering that my sid is
full-disk encrypted, there is something odd, here.

Thx, bye,
Gismo / Luca
 

Thread Tools




All times are GMT. The time now is 01:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org