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 08-31-2012, 03:04 PM
Jon Dowland
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Fri, Aug 31, 2012 at 10:57:10PM +0800, Thomas Goirand wrote:
> On 08/31/2012 06:55 PM, Riku Voipio wrote:
> > How is that different from having a botched / or /boot ? Why do you
> > think having a separate /usr will make / less prone to HD crashes?
> > You have / on RAID5 while /usr isn't?
> >
>
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server setup.
>
> Also, / is a partition on which almost nothing is read or written, while
> the others (eg: /usr, /var, /tmp, swap) are a lot more I/O intensive.
> Which means that / is less prone to failure. Often, the 2nd RAID
> array gets degraded, but / isn't. So it does make a lot of sense to
> setup things this way, and yes, / is less prone to HD crashes this
> way (I'm talking from 10 years of experience running about 100
> servers this way, so it's not just theory, it's very practical experience).

I'm struggling to understand this. In the situation you outline (/ ok,
/usr, /var, /tmp, swap on another RAID which is hosed) -- whatever service
the machine was offering is surely not being offered anymore (/ being too
small to be useful for anything except a rescue environment). So / surviving
whilst all your services/data are dead doesn't seem to be a big win to me at
all. Am I missing a detail?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120831150447.GD24379@debian
 
Old 08-31-2012, 03:52 PM
Peter Samuelson
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server setup.

I guess I can understand that you want your /usr to be resizeable, but
really, life is so much simpler when you just go ahead and create a 12
GB root filesystem (and no separate /usr) and be done with it. The
days have long passed when that 10 or 11 GB of wasted space was
anything to worry about.

> Also, / is a partition on which almost nothing is read or written,
> while the others (eg: /usr, /var, /tmp, swap) are a lot more I/O
> intensive. Which means that / is less prone to failure.

I always thought reads were pretty harmless and it's mostly writes you
have to worry about (both for bugs in the OS FS, and for the physical
media). And both / and /usr should have very few writes,
percentage-wise.

I used to think keeping / fully self-contained was useful. But it is a
non-zero amount of effort, and I'm becoming convinced that these days,
the separate /usr is going the way of the shared /usr/share.

Peter


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120831155225.GB4352@p12n.org">http://lists.debian.org/20120831155225.GB4352@p12n.org
 
Old 08-31-2012, 06:17 PM
Thomas Goirand
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 08/31/2012 11:04 PM, Jon Dowland wrote:
> I'm struggling to understand this. In the situation you outline (/ ok,
> /usr, /var, /tmp, swap on another RAID which is hosed) -- whatever service
> the machine was offering is surely not being offered anymore (/ being too
> small to be useful for anything except a rescue environment). So / surviving
> whilst all your services/data are dead doesn't seem to be a big win to me at
> all. Am I missing a detail?
>
The rootfs contains all the configuration (eg: /etc), and stuff
like /etc/lvm/archive/, RAID UUID, and all sorts of things which
are vital if you want to have any chance of recovering the rest
(eg: your data hosted in /var).

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5040FFAA.7030006@debian.org">http://lists.debian.org/5040FFAA.7030006@debian.org
 
Old 08-31-2012, 06:29 PM
Thomas Goirand
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On 08/31/2012 11:52 PM, Peter Samuelson wrote:
> I guess I can understand that you want your /usr to be resizeable

Not only this. I want it on a RAID10 or RAID5 which goes faster than
my / that is hosted in a slower RAID1.

> but
> really, life is so much simpler when you just go ahead and create a 12
> GB root filesystem (and no separate /usr) and be done with it.

Maybe more simple, but then I will loose the advantages that I
already explained. And more importantly: I don't care simple.

> The
> days have long passed when that 10 or 11 GB of wasted space was
> anything to worry about.
>

This has nothing to do with the amount of space.
But if you want to go on that ground...

Today, you say 10GB. What about in 5 years? Can
you easily predict what will be my needs? I don't.

> I always thought reads were pretty harmless and it's mostly writes you
> have to worry about (both for bugs in the OS FS, and for the physical
> media). And both / and /usr should have very few writes,
> percentage-wise.
>

It depends what you do, I'd say. But yes of course, you'd have very few,
and even maybe zero once the system is setup, writes on /usr. But if
your computer has a lot of activities taking a lot of RAM, chances are
that stuff will be kicked out of the cache and get read again.

> I used to think keeping / fully self-contained was useful. But it is a
> non-zero amount of effort, and I'm becoming convinced that these days,
> the separate /usr is going the way of the shared /usr/share.
>
> Peter
>

Isn't it because you are just becoming a bit lazy?

You could also have tell me to use just one single partition, and
that having a separate /tmp, /var and so on totally useless too.
We could argue as well during huge threads about it.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50410280.4030008@debian.org">http://lists.debian.org/50410280.4030008@debian.org
 
Old 09-01-2012, 11:13 AM
Wouter Verhelst
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

On Fri, Aug 31, 2012 at 10:57:10PM +0800, Thomas Goirand wrote:
> On 08/31/2012 06:55 PM, Riku Voipio wrote:
> > How is that different from having a botched / or /boot ? Why do you
> > think having a separate /usr will make / less prone to HD crashes?
> > You have / on RAID5 while /usr isn't?
> >
>
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server setup.

Since you're talking of software RAID and LVM, that means you need an
initramfs to boot your system. Thus, your systems will continue to boot
with the proposed scenario, which supports booting with /usr on a
separate filesystem if you have an initramfs.

What exactly is the problem?

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120901111325.GC18416@grep.be">http://lists.debian.org/20120901111325.GC18416@grep.be
 
Old 09-01-2012, 06:25 PM
Matthew Woodcraft
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Wouter Verhelst wrote:
> Since you're talking of software RAID and LVM, that means you need an
> initramfs to boot your system. Thus, your systems will continue to
> boot with the proposed scenario, which supports booting with /usr on a
> separate filesystem if you have an initramfs.

Using software RAID and LVM does not require an initramfs.

Debian has supported booting from md RAID without using an initramfs for
a very long time.

GRUB2 can boot from LVM or a separate /boot, but in any case risk-averse
people might choose to avoid root-on-LVM; this is one of the reasons for
putting /usr on a separate filesystem in the first place.


The system I'm sending this email from would fail to boot if separate
/usr without initramfs stops being supported. If Debian doesn't want to
continue doing the work to support that configuration, fair enough; I'll
change. But I'd like to correct the impression that such systems don't
exist.

-M-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120901182508.GA21447@golux.woodcraft.me.uk">http ://lists.debian.org/20120901182508.GA21447@golux.woodcraft.me.uk
 
Old 09-01-2012, 08:53 PM
Steve Langasek
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Hi Matthew,

On Sat, Sep 01, 2012 at 07:25:09PM +0100, Matthew Woodcraft wrote:
> Wouter Verhelst wrote:
> > Since you're talking of software RAID and LVM, that means you need an
> > initramfs to boot your system. Thus, your systems will continue to
> > boot with the proposed scenario, which supports booting with /usr on a
> > separate filesystem if you have an initramfs.

> Using software RAID and LVM does not require an initramfs.

> Debian has supported booting from md RAID without using an initramfs for
> a very long time.

True but misleading. LILO supported it because it hard-coded the block list
of the kernel and initrd at install time. GRUB1 never supported any RAID
except for RAID1, as far as I'm aware. GRUB2 has supported RAID5 since
~2008, but has only been used as the default boot loader in Debian since
2011; prior to that the installer would select the best bootloader for the
chosen disk layout - but grub2 was sufficiently experimental at that point
that no one who actually cared about their data would be using it.

As for LVM, I'm not aware of any implementation that supports kernel
auto-activation of VGs without an initramfs.

> GRUB2 can boot from LVM or a separate /boot, but in any case risk-averse
> people might choose to avoid root-on-LVM; this is one of the reasons for
> putting /usr on a separate filesystem in the first place.

I wouldn't call this being risk averse, I would call it being *bad* at risk
assessment / risk management. All the interesting data needed for running
the system is on a filesystem other than the root filesystem in that case.
If you actually think LVM isn't safe, you shouldn't be using it for /usr
(and /var). If you think it is safe, you should have / on it as well and,
if necessary, allocate a separate /boot partition for the bootloader.

> The system I'm sending this email from would fail to boot if separate
> /usr without initramfs stops being supported.

Can you please elaborate on why that is? Is there something in your
configuration that would prevent an initramfs from being automatically used
by the bootloader when generated at kernel install time? Are there
particular constraints on your environment that would prevent the system
from using an initramfs if one was required (e.g., would there be some
reason you would have to reinstall to adapt to such new requirements)?

> If Debian doesn't want to continue doing the work to support that
> configuration, fair enough; I'll change. But I'd like to correct the
> impression that such systems don't exist.

My assertion isn't that an initramfsless system with /usr as a separate
filesystem can't be done; my assertion is, rather, than it is an
uninteresting configuration to support and that dropping support for it
won't negatively impact our users. If I'm mistaken about this, I'd
certainly like to know it.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 09-01-2012, 10:30 PM
Steve Langasek
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Hi Thomas,

On Fri, Aug 31, 2012 at 05:39:14PM +0800, Thomas Goirand wrote:
> On 08/31/2012 03:39 AM, Steve Langasek wrote:
> > - /usr on a separate filesystem without the use of an initramfs: not
> > supported... and no discernable user demand for this.

> Well, let's say I have a big crash, and I want to recover, and I
> need to access /etc/lvm/archive in a single user, with of course
> my /usr in a bad state, and I wouldn't be able to mount it for
> various reasons. Let's say, an HDD crash, which is very common.

> If I need to have /usr mounted before init starts, then I'm more
> or less dead, and I'll have to get a recovery CD / USB.

> If I don't need /usr, everything is fine, I can boot into single
> user mode, and repair.

> Guess which situation I prefer?

There's no reason that you should be "more or less dead". The proposed
design still allows for recovery - it just requires that you use the
initramfs as the recovery environment, rather than the rootfs. The
difference is about where we put our bootstrapping/recovery environment and
how we package it, not about whether we have one.

> Now, you tell me: what are the advantage of requiring having
> everything in /usr exactly? I really don't get what the advantage is.

The advantages have been laid out in the Fedora spec. The only additional
advantage not mentioned there is that it saves us from fighting an uphill
battle against upstreams - not just those who have adopted the Fedora design
and are entangling /usr with things like /lib/udev, but even upstreams like
GNU autotools, which really doesn't support the idea of separate heirarchies
for boot-critical libraries vs. dev packages.

> On 08/31/2012 03:39 AM, Steve Langasek wrote:
> > However, I struggled to formulate a concrete
> > scenario where losing support for that last configuration would actually
> > make a difference.

> You must have not read some of my posts then.

I don't recall if I did or not. But certainly in this post, you're not
presenting anything that can't be supported under the new proposal, just
something that has to be supported differently.

> Also, please make the point into why having stuff in /usr is
> to be preferred. Or is it that the *only* argument that you
> have is that we are polluted by RedHat crap? If so, why
> shouldn't we consider switching to an alternative of udev
> like mdev, if its development goes on the right direction,
> for Jessie?

This is a profound misunderstanding of the problem. udev is not the issue.
udev rules *provided by other desktop packages* are the issue.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120901223010.GC22807@virgil.dodds.net">http://lists.debian.org/20120901223010.GC22807@virgil.dodds.net
 
Old 09-02-2012, 01:49 AM
Darren Salt
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

I demand that Steve Langasek may or may not have written...

[snip]
> The Fedora implementation does not require us to drop support for /usr as a
> separate filesystem. It only requires us to ensure /usr is mounted before
> init is started.
>
> - /usr as a separate filesystem mounted from an initramfs: supported
> - /usr on the root filesystem: supported

Fine...

> - /usr on a separate filesystem without the use of an initramfs: not
> supported... and no discernable user demand for this.

I use exactly that on most computers which I've set up (primary exception
being a netbook, due to limited storage), and I don't want an initramfs.
There may come a time when I decide to change this in favour of no separate
/usr partition, but I very much doubt that it'll be before I need to replace
hardware.

I've carefully avoided use of initramfs images; I don't plan to start using
them just so that /usr can be mounted early.

You can call it irrational or whatever else you like; I don't care.

> My knee-jerk reaction to the Fedora proposal had been that it was sick and
> wrong and would cause unacceptable breakage for users on upgrades if Debian
> adopted the same plan. However, I struggled to formulate a concrete
> scenario where losing support for that last configuration would actually
> make a difference.

Upgrade-in-place ‘legacy’, if you like.

[snip; not worth maintaining the distinction?]
> This, plus the extensive upstream use (IMHO misuse) of software installed
> to /usr as part of udev rules, means that in reality an ever increasing
> number of libraries need to be shipped in /lib to properly handle
> bootstrapping the mount of /usr using only the contents of /.

My opinion? Misuse, with the intention of moving away from separate /usr.

> In contrast, if we use an initramfs to handle mounting of /usr, we move all
> the complexity out of the packaging and instead pull components into the
> small initramfs only as needed. As far as I've been able to determine,
> there really is no downside to the user from making this switch.

For me, the presence of an initramfs is a downside when I've been able to do
without without problem for so long.

--
| _ | Darren Salt, using Debian GNU/Linux (and Android)
| ( ) |
| X | ASCII Ribbon campaign against HTML e-mail
| / | http://www.asciiribbon.org/

I'm not a complete idiot - some parts are missing.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 52CE18BC8C%listspam@moreofthesa.me.uk">http://lists.debian.org/52CE18BC8C%listspam@moreofthesa.me.uk
 
Old 09-02-2012, 03:48 AM
Nikolaus Rath
 
Default Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

Darren Salt <listspam@moreofthesa.me.uk> writes:
> I've carefully avoided use of initramfs images; I don't plan to start using
> them just so that /usr can be mounted early.
>
> You can call it irrational or whatever else you like; I don't care.
[..]
>
> For me, the presence of an initramfs is a downside when I've been able to do
> without without problem for so long.

Disliking initramfs for no technical reason is of course something you
are free to do. But why should this affect any decision that Debian
makes about requiring or not requiring initramfs?


Curious,

-Nikolaus

--
Time flies like an arrow, fruit flies like a Banana.

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txvhqe3a.fsf@vostro.rath.org">http://lists.debian.org/87txvhqe3a.fsf@vostro.rath.org
 

Thread Tools




All times are GMT. The time now is 10:42 PM.

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