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

 
 
LinkBack Thread Tools
 
Old 07-01-2012, 05:40 AM
Les Mikesell
 
Default Question about storage for virtualisation

On Sat, Jun 30, 2012 at 10:30 AM, Stephen Harris <lists@spuddy.org> wrote:
> On Sat, Jun 30, 2012 at 09:56:59AM -0500, Les Mikesell wrote:
>
>> devices in these days of 3TB drives.... * I suppose most of what /bin
>> was supposed to hold and the reasons for putting it there have been
>> usurped by the initrd that is normally required to boot linux, though.
>
> Historically for Linux /bin and /sbin were meant to hold the minimum
> necessary tools to bring the rest of the filesystems online and to do
> basic restores in case the thing exploded (basically, "single user mode"
> tools). *Everything else was meant to be in /usr. */lib requirements came
> from /bin. *At least that was the rationale we put into FSSTND back in the
> early-mid 90s. *(I'm not sure RedHat ever really followed this properly;
> there's too much stuff in /bin :-))
>
> With initrd and similar ramdisk boot systems these requirements have
> changed and the distinction between /bin and /usr/bin has definitely
> dropped.

The concept really comes from the original unix, which back in the
day, often had really tiny boot disks and might mount everything else
over the network or use different drive types to hold the larger /usr
space. And it would still be nice to be able to do that from a small
flash disk, etc. But you are right, I don't think Linux ever did it
correctly anyway....

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 01:48 PM
Tilman Schmidt
 
Default Question about storage for virtualisation

Am 01.07.2012 07:40, schrieb Les Mikesell:
[distinction between /bin and /usr/bin]
> The concept really comes from the original unix, which back in the
> day, often had really tiny boot disks and might mount everything else
> over the network or use different drive types to hold the larger /usr
> space.

The separation predates Unix networking. IIRC /usr/bin was
already there on Unix Version 7 on the PDP-11, before Ethernet
was even invented.

--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 02:04 PM
Giles Coochey
 
Default Question about storage for virtualisation

On 02/07/2012 14:48, Tilman Schmidt wrote:

Am 01.07.2012 07:40, schrieb Les Mikesell:
[distinction between /bin and /usr/bin]

The concept really comes from the original unix, which back in the
day, often had really tiny boot disks and might mount everything else
over the network or use different drive types to hold the larger /usr
space.

The separation predates Unix networking. IIRC /usr/bin was
already there on Unix Version 7 on the PDP-11, before Ethernet
was even invented.


As Rob@landley.net mentioned on the busybox list a couple of years ago:

Understanding the bin, sbin, usr/bin , usr/sbin split

You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one, which is where all the
user home directories lived (which is why the mount was called /usr). They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and
wrote files to those new directories because their original disk was out of
space. When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

Of course they made rules about "when the system first boots, it has to come up
enough to be able to mount the second disk on /usr, so don't put things like
the mount command /usr/bin or we'll have a chicken and egg problem bringing
the system up." Fairly straightforward. Also fairly specific to v6 unix of 35
years ago.

The /bin vs /usr/bin split (and all the others) is an artifact of this, a
1970's implementation detail that got carried forward for decades by
bureaucrats who never question _why_ they're doing things. It stopped making
any sense before Linux was ever invented, for multiple reasons:

1) Early system bringup is the provice of initrd and initramfs, which deals
with the "this file is needed before that file" issues. We've already _got_ a
temporary system that boots the main system.

2) shared libraries (introduced by the Berkeley guys) prevent you from
independently upgrading the /lib and /usr/bin parts. They two partitions have
to _match_ or they won't work. This wasn't the case in 1974, back then they
had a certain level of independence because everything was statically linked.

3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and
partition resizing software showed up somewhere around there (partition magic
3.0 shipped in 1997).

Of course once the split existed, some people made other rules to justify it.
Root was for the OS stuff you got from upstream and /usr was for your site-
local files. Then / was for the stuff you got from AT&T and /usr was for the
stuff that your distro like IBM AIX or Dec Ultrix or SGI Irix added to it, and
/usr/local was for your specific installation's files. Then somebody decided
/usr/local wasn't a good place to install new packages, so let's add /opt!
I'm still waiting for /opt/local to show up...

Of course given 30 years to fester, this split made some interesting distro-
specific rules show up and go away again, such as "/tmp is cleared between
reboots but /usr/tmp isn't". (Of course on Ubuntu /usr/tmp doesn't exist and
on Gentoo /usr/tmp is a symlink to /var/tmp which now has the "not cleared
between reboots" rule. Yes all this predated tmpfs. It has to do with read-
only root filesystems, /usr is always going to be read only in that case and
/var is where your writable space is, / is _mostly_ read only except for bits
of /etc which they tried to move to /var but really symlinking /etc to
/var/etc happens more often than not...)

Standards bureaucracies like the Linux Foundation (which consumed the Free
Standards Group in its' ever-growing accretion disk years ago) happily
document and add to this sort of complexity without ever trying to understand
why it was there in the first place. 'Ken and Dennis leaked their OS into the
equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes
whoosh over their heads.

I'm pretty sure the busybox install just puts binaries wherever other versions
of those binaries have historically gone. There's no actual REASON for any of
it anymore. Personally, I symlink /bin /sbin and /lib to their /usr
equivalents on systems I put together. Embedded guys try to understand and
simplify...

Rob
--
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.



--
Regards,

Giles Coochey, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
giles@coochey.net

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 03:00 PM
Stephen Harris
 
Default Question about storage for virtualisation

On Mon, Jul 02, 2012 at 03:04:50PM +0100, Giles Coochey wrote:

> As Rob@landley.net mentioned on the busybox list a couple of years ago:

> bureaucrats who never question _why_ they're doing things. It stopped
> making
> any sense before Linux was ever invented, for multiple reasons:
>
> 1) Early system bringup is the provice of initrd and initramfs, which deals
> with the "this file is needed before that file" issues. We've already
> _got_ a
> temporary system that boots the main system.

Which, of course, is a fallacy. Back when we did FSSTND the concept of
initrd/initramfs wasn't used. It still wasn't too unusual to use rdev to
set the root disk in the kernel image rather than pass it as a parameter
via LILO. (I'm not sure when initrd became usable; it might have been
around 2000. According to http://www.linuxsymposium.org/2000/booting.php
ramdisks only appeared in the kernel in 1996 and pivot_root in 2000.
Thus initrd didn't exist when FSSTND was written... in 1993/1994.
Hardly "before Linux was ever invented".)

> 2) shared libraries (introduced by the Berkeley guys) prevent you from
> independently upgrading the /lib and /usr/bin parts. They two partitions
> have

Irrelevant to the discussion. "Independence" of / and /usr was never
an argument in the Linux space.

> 3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and
> partition resizing software showed up somewhere around there (partition
> magic
> 3.0 shipped in 1997).

Hmm, we did FSSTND in 1993/1994 timeframe. At this time, considering
that for many people this was a 2nd OS dual-booted with DOS/Windows
3, we dealt with smaller partitions spread potentially on the end of
multiple disks that DOS couldn't use (8Mb at the end of a 40Mb disk
'cos of the 32Mb limit of the time. Woohoo, I had two of these disks!).

> Root was for the OS stuff you got from upstream and /usr was for your site-
> local files. Then / was for the stuff you got from AT&T and /usr was for
> the

That was never in FSSTND, and it wasn't in the SVR4 definition documents
(which I used a fair bit to help steer the FSSTND discussion).

Basically, Rob is incorrect as to the Linux rationale. We kept the /
and /usr split to be _consistent_ with existing practice and to allow
small and hobbyist systems to be usable.

_TODAY_ (where I have an MMC card in my wallet that's almost 1000 times
bigger than that old hard disk!) the rationale for a / and /usr split is a
lot less. We _do_ commonly use ramdisk based boot systems, we _do_ have
disk space to spare. If we were to redo FSSTND (er, FHS as it became)
today then it's likely that decisions like the / /usr split would have
been decided differently.

I'm not convinced a /XX -> /usr/XX symlink solution buys us very
much (for cross-platform compatibility people will still have
/usr/local/bin:/usr/bin:/bin as PATHs) but I'm also not convinced
it'll cause any real problems.

If you want a historical look as to some of the reasons why we did
what we did,
http://www.ibiblio.org/pub/Linux/docs/fsstnd/old/fsstnd-1.0/FSSTND-FAQ

--

rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 03:56 PM
Les Mikesell
 
Default Question about storage for virtualisation

On Mon, Jul 2, 2012 at 10:00 AM, Stephen Harris <lists@spuddy.org> wrote:
>
> _TODAY_ (where I have an MMC card in my wallet that's almost 1000 times
> bigger than that old hard disk!) the rationale for a / and /usr split is a
> lot less.

No it isn't. There are still good reasons to not require unnecessary
stuff on your boot device in spite of the fact that you've managed to
find one way to work around the problem on one kind of hardware at a
cost you can afford. And the the Linux layout pretty much forces
everyone else to do the same.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 04:00 PM
 
Default Question about storage for virtualisation

Giles Coochey wrote:
> On 02/07/2012 14:48, Tilman Schmidt wrote:
>> Am 01.07.2012 07:40, schrieb Les Mikesell:
>> [distinction between /bin and /usr/bin]
<nice summary snipped>
> 3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and
> partition resizing software showed up somewhere around there (partition
> magic 3.0 shipped in 1997).

Um, nope. 100M drives weren't "cheap" until well into the nineties.
*Companies* could afford them by '92 or '93. '90? I think it was the
holiday season of '89 that my bosses in the tiny, tiny software co. I
worked for gave us presents, and mine include a *huge* 30M h/d (*way*
bigger than the 20M I had), knowing they'd get use of it, with me working
at home one weekends....
<snip>
> /usr/local was for your specific installation's files. Then somebody
> decided /usr/local wasn't a good place to install new packages, so let's
> add /opt! I'm still waiting for /opt/local to show up...

Sun added /opt; I think Oracle used it, too, about the same time.

At least here, my manager believes in /usr/local....
<snip>

mark

> --
> GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke
> Nukem Forever, and as welcome as New Coke.

ROFTL!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 04:23 PM
Stephen Harris
 
Default Question about storage for virtualisation

On Mon, Jul 02, 2012 at 10:56:50AM -0500, Les Mikesell wrote:
> On Mon, Jul 2, 2012 at 10:00 AM, Stephen Harris <lists@spuddy.org> wrote:
> >
> > _TODAY_ (where I have an MMC card in my wallet that's almost 1000 times
> > bigger than that old hard disk!) the rationale for a / and /usr split is a
> > lot less.
>
> No it isn't. There are still good reasons to not require unnecessary
> stuff on your boot device in spite of the fact that you've managed to

Your boot device can be (typically is) different to your root device.
And even if you really meant "root" then this merger moves stuff _off_
the root disk and puts it onto /usr. Properly done /usr can still be
a separate partition, if desired; initrd just needs to mount it.

So this proposal can make the root disk _smaller_ than it currently is.

--

rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 06:18 PM
Les Mikesell
 
Default Question about storage for virtualisation

On Mon, Jul 2, 2012 at 11:23 AM, Stephen Harris <lists@spuddy.org> wrote:
>
>> > _TODAY_ (where I have an MMC card in my wallet that's almost 1000 times
>> > bigger than that old hard disk!) the rationale for a / and /usr split is a
>> > lot less.
>>
>> No it isn't. There are still good reasons to not require unnecessary
>> stuff on your boot device in spite of the fact that you've managed to
>
> Your boot device can be (typically is) different to your root device.
> And even if you really meant "root" then this merger moves stuff _off_
> the root disk and puts it onto /usr. Properly done /usr can still be
> a separate partition, if desired; initrd just needs to mount it.

You aren't done booting until you complete the init scripts for
runlevel 1. Having to have an extra copy of the kernel on yet another
device to even get started seems wrong from a minimalist approach, and
the need for sufficient ram for an initrd even more so. And you
really should be able to mount /usr via nfs while retaining
independent boot/diagnostic capability.

> So this proposal can make the root disk _smaller_ than it currently is.

What's the problem with just following $PATH?

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 06:25 PM
Gordon Messmer
 
Default Question about storage for virtualisation

On 07/02/2012 08:56 AM, Les Mikesell wrote:
> There are still good reasons to not require unnecessary
> stuff on your boot device in spite of the fact that you've managed to
> find one way to work around the problem on one kind of hardware at a
> cost you can afford.

Typically your boot device is mounted at /boot (or, arguably, is the
initrd) which isn't affected by the merge.

Personally, I think the merge is perfectly well reasoned, and I'm glad
to see the system simplified. However, the wisdom of the merge is no
longer a useful debate. It is coming, and separating / and /usr in your
partitioning is no longer advised. You will lose functionality in
future releases if you continue to do so.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-02-2012, 06:42 PM
Stephen Harris
 
Default Question about storage for virtualisation

On Mon, Jul 02, 2012 at 01:18:58PM -0500, Les Mikesell wrote:
> You aren't done booting until you complete the init scripts for
> runlevel 1. Having to have an extra copy of the kernel on yet another
> device to even get started seems wrong from a minimalist approach, and

There's no extra kernel image needed. Kernel comes from /boot, just as
today. You need to copy a few modules into the ramdisk so that drivers
can be initialised, and you need a few user-space utilities (on RedHat 5
these are mostly provided by "nash"; RedHat 6 is a lot more detailed in
the initramfs image).

> the need for sufficient ram for an initrd even more so. And you

Yes, this is one downside to the proposal; you can't have a separate
/usr partition on RAM limited machines (with RedHat you need, maybe, 4Mb
of RAM for the initrd; with RedHat 6 that is gone up a lot). The
memory should be free'd back once the switch to real-root has been made
so it's temporary but, yes, it is a requirement if you want separate
/ and /usr partitions.

But, equally, these are likely to be storage limited machines as well (e.g
embedded devices) so aren't likely to want to waste space on partioning
losses or will be using nfsroot, so this edge case isn't a likely case.

And if you _do_ have this pathological edge case then you don't have to
follow the Fedora standard; you're gonna be going your own way, anyway!

> really should be able to mount /usr via nfs while retaining
> independent boot/diagnostic capability.

You can. Nothing in this proposal stops this.

> What's the problem with just following $PATH?

I've no idea. It's not my proposal. I don't see the _need_ to do it;
indeed I said that most people will still set PATH to include bin and
usr/bin simply 'cos of cross-OS compatibility (AIX, HPUX, other Linuxen
etc).

I'm just saying that I don't see it causing any true pain.

--

rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 05:04 AM.

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