Hi !
I'm about to deploy a new server that will host several virtual host for mainly website hosting purposes. My server will be a Xeon 3440 or 3450 with 32 gigs of ram (the max of that board). So I will have 8 logical cores. At the moment, I don't know how many vms I will have, in the order of 5 or 6.
I am quite new to managing VMs, I did play alot with them over the course of the last couple of weeks. I used kvm to startup and manage my vms and my main source of info was this blog entry : http://blog.mattbrock.co.uk/2012/02/12/virtualisation-with-kvm-and-lvm-on-ce...
I have some general questions about VM.
If I set vcpu let's say to 2-3 for a single vm, does this mean that those CPU are dedicated to that vm or many vm can share the same physicial cpus ?
So, I was wondering what's the best for managing storage for VMs ? I see mostly recomandations for LV for storing VM's disks. It seem to helps to create snapshots for backup purposes. Is this the fastest way of creating backups ? And will data access be faster that if I use regular files ?
In my case, the "main" setup of each vm is rather simple. The minimal OS, updates, my own httpd, my own php a couple of other packages. So restoring a VM from scratch can take less than an hour. So I was thinking of not taking snapshot of the whole VM and only sync the data partition.
As for the guest paritions, I am accustomed of separating my servers disks with separate /, /usr, /var, /home and /data partitions. I can't recall today why I started doing this, 15 years ago, but I still like it that way and continue to do so. Do I still "need" to do this with VMs ?
Thanks for the help !
On Tue, Jun 26, 2012 at 9:05 AM, Nicolas Ross rossnick-lists@cybercat.ca wrote:
I have some general questions about VM.
If I set vcpu let's say to 2-3 for a single vm, does this mean that those CPU are dedicated to that vm or many vm can share the same physicial cpus ?
No, all the CPU will be virtualized and shared. Although there is "affinity" option where physical CPU is locked to a certain VM. But in general this option gives more bad effect than good.
So, I was wondering what's the best for managing storage for VMs ? I see mostly recomandations for LV for storing VM's disks. It seem to helps to create snapshots for backup purposes. Is this the fastest way of creating backups ? And will data access be faster that if I use regular files ?
Using LV will give you flexibility among other things. Better have it in the beginning rather than sorry later (e.g. running out of space, etc). The performance difference is insignificant.
In my case, the "main" setup of each vm is rather simple. The minimal OS, updates, my own httpd, my own php a couple of other packages. So restoring a VM from scratch can take less than an hour. So I was thinking of not taking snapshot of the whole VM and only sync the data partition.
That's ok.
As for the guest paritions, I am accustomed of separating my servers disks with separate /, /usr, /var, /home and /data partitions. I can't recall today why I started doing this, 15 years ago, but I still like it that way and continue to do so. Do I still "need" to do this with VMs ?
The reason of creating separate partitions is mainly for security and preserve data during reinstallation. I believe it's still good to do your way.
On 06/25/2012 06:05 PM, Nicolas Ross wrote:
If I set vcpu let's say to 2-3 for a single vm, does this mean that those CPU are dedicated to that vm or many vm can share the same physicial cpus ?
Normally, they won't be dedicated. You cannot assign more CPUs to a guest than there are in the host system, but you can overcommit CPUs in general. That is, if you have 8 cores, you can create two guests with 6 virtual CPUs each. If the guests both become busy enough to fully utilize 6 CPUs, the performance of each will naturally be degraded relative to only one guest being busy enough to fully utilize 6 CPUs.
While CPUs cannot be overcommitted, memory can. Again, if you overcommit memory, the host will swap excess utilization and severely degrade guest performance. Take care to avoid doing this.
So, I was wondering what's the best for managing storage for VMs ? I see mostly recomandations for LV for storing VM's disks. It seem to helps to create snapshots for backup purposes. Is this the fastest way of creating backups ? And will data access be faster that if I use regular files ?
Yes, performance of guests backed by LVs will be significantly better than the performance of guests backed by regular files.
No, you cannot make reliable backups of guests using snapshots of the LV. A snapshot taken at any given time may have inconsistent data. Run your backup software in the guest rather than in the host. Under a Linux guest, you're able to snapshot filesystems and make backups.
When you make a snapshot under LVM, the file system contained therein is made consistent (though I'm having trouble finding actual documentation to that effect) before the snapshot is taken. If you have open files, you may need to take additional steps to make that data consistent (as you would if you were backing up a MySQL database). Taking a snapshot of a running KVM guest will not make data consistent, so you won't be able to reliably make a backup that way.
Finally, do not use snapshots as your primary means of backup. If your media fails, you will lose your data.
As for the guest paritions, I am accustomed of separating my servers disks with separate /, /usr, /var, /home and /data partitions. I can't recall today why I started doing this, 15 years ago, but I still like it that way and continue to do so. Do I still "need" to do this with VMs ?
I don't believe there's any more or less need to do so. I would strongly recommend that you not segregate / and /usr. Fedora and future versions of RHEL/CentOS will expect a unified / and /usr.
On 06/26/12 9:29 AM, Gordon Messmer wrote:
As for the guest paritions, I am accustomed of separating my servers
disks with separate /, /usr, /var, /home and /data partitions. I can't recall today why I started doing this, 15 years ago, but I still like it that way and continue to do so. Do I still "need" to do this with VMs ?
I don't believe there's any more or less need to do so. I would strongly recommend that you not segregate / and /usr. Fedora and future versions of RHEL/CentOS will expect a unified / and /usr. _______________________________________________
I concur. I'll definitely put /home on a seperate volume if there's going to be a need for a large /home (some of my servers have hardly any /home as there are no interactive users to speak of, others use nfs mounted /home dirs for interactive logins). /var I'm kind of on the fence on. things like postgres, which like to put the databases in /var/lib/pgsql/x.y/data, I've been recently mounting my dedicated raid10 database volumes as such, so /var itself has very little. but we all know spools, logs can grow unexpectedly large, so constraining /var to a dedicated LV is probably a good idea.
On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
I don't believe there's any more or less need to do so. I would strongly recommend that you not segregate / and /usr. Fedora and future versions of RHEL/CentOS will expect a unified / and /usr.
I may be behind, but this is the first I've heard of this...
Any good references as to WHY?! they want to break this decades old convention?
Thanks,
Nate
On Fri, 29 Jun 2012, Nate Duehr wrote:
On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
I don't believe there's any more or less need to do so. I would strongly recommend that you not segregate / and /usr. Fedora and future versions of RHEL/CentOS will expect a unified / and /usr.
I may be behind, but this is the first I've heard of this...
Any good references as to WHY?! they want to break this decades old convention?
Solaris broke it years ago.
It'll certainly help builds and packaging, since no one needs to specify where, e.g., ls or rm is located.
And granted that my experience is far from universal, I haven't seen a production Linux box that remote-mounts /usr in a decade.
Am 29.06.2012 20:17, schrieb Nate Duehr:
On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
I don't believe there's any more or less need to do so. I would strongly recommend that you not segregate / and /usr. Fedora and future versions of RHEL/CentOS will expect a unified / and /usr.
I may be behind, but this is the first I've heard of this...
Any good references as to WHY?! they want to break this decades old convention?
Decades old I'll grant you, but hardly a convention anymore. There was a time when this made sense ... about twenty-five years ago. We didn't have journaling filesystems then, fsck was still new, and if your root filesystem was corrupted you had to boot to single user mode in order to fix it manually. You had every interest to keep your root filesystem small, simple and static.
But times have changed. Nowadays, a system that has experienced a power cut in full activity will come back up with hardly a hiccup when power is restored. Dividing up your disks into partitions has become a nuisance because there's always one which is too small while others have space left. So it's gone out of fashion. I haven't seen a Unix or Linux system with separate / and /usr partitions in the last five years, and not set one up myself for ten at least.
On 06/29/2012 11:17 AM, Nate Duehr wrote:
Any good references as to WHY?! they want to break this decades old convention?
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
All of the reasons you'd put /usr on a separate partition from / were resolved decades ago. There's no reason to do that, and a long list of reasons not to.
On Fri, Jun 29, 2012 at 11:19 PM, Gordon Messmer yinyang@eburg.com wrote:
On 06/29/2012 11:17 AM, Nate Duehr wrote:
Any good references as to WHY?! they want to break this decades old convention?
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
All of the reasons you'd put /usr on a separate partition from / were resolved decades ago. There's no reason to do that, and a long list of reasons not to.
Umm, yeah... Nobody would ever want to boot from small alternate media 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.
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.
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....
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.
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
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:
- 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".)
- 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.
- 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
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.
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.
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?
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.
On Mon, Jul 2, 2012 at 1:42 PM, Stephen Harris lists@spuddy.org wrote:
I'm just saying that I don't see it causing any true pain.
It may not - but it is always annoying to me when committees get together and move arbitrary things around just because they can. And even more so when they want to turn Linux, whose success is clearly based on the unix design into something that is not like unix.
On 07/02/2012 12:00 PM, Les Mikesell wrote:
It may not - but it is always annoying to me when committees get together and move arbitrary things around just because they can.
The change wasn't made just because someone could. It was made to improve software and script portability, to make and NFS-mounted /usr a supported configuration, and to allow yum to take system snapshots so that it can roll back upgrades in the future. All of those required the merge.
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
On 07/02/2012 11:18 AM, Les Mikesell wrote:
You aren't done booting until you complete the init scripts for runlevel 1.
You may not have noticed, but there is no longer any such thing. Red Hat's init system never booted *through* runlevel 1, the way that some other Unix systems did.
Even on older Red Hat systems, /usr is mounted before the runlevel 1 scripts run. It's mounted in rc.sysinit. By your logic, you aren't done booting until you have both / and /usr mounted, so there's no value in separating them.
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.
No part of the merge requires and additional copy of the kernel or initrd, and I'm not sure where your confusion on the subject originates.
Prior to the merge, you could not reliably mount /usr from NFS, since it might not match the libraries in /. Merging / in to /usr actually makes an NFS root filesystem a supported configuration, which was not previously the case.
Twice in this message, you've actually argued *for* merging the two without realizing it.
On Mon, Jul 2, 2012 at 2:08 PM, Gordon Messmer yinyang@eburg.com wrote:
You aren't done booting until you complete the init scripts for runlevel 1.
You may not have noticed, but there is no longer any such thing. Red Hat's init system never booted *through* runlevel 1, the way that some other Unix systems did.
Yes, I noticed - and didn't see the point in that either. Why copy the runlevel 'look' of sysV if you aren't going to take advantage of it?
Even on older Red Hat systems, /usr is mounted before the runlevel 1 scripts run. It's mounted in rc.sysinit. By your logic, you aren't done booting until you have both / and /usr mounted, so there's no value in separating them.
Right. It was broken before. Which is mostly why I don't have a lot of faith in the next round of changes either.
Prior to the merge, you could not reliably mount /usr from NFS, since it might not match the libraries in /. Merging / in to /usr actually makes an NFS root filesystem a supported configuration, which was not previously the case.
Twice in this message, you've actually argued *for* merging the two without realizing it.
I was arguing against the broken ways that the layout has diverged from the unix design concepts more than any specific thing. If this is going to make everything work again, great. This time for sure...
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.
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>
- 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!
On Mon, 2012-07-02 at 15:48 +0200, 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.
You are correct. I used to create and mail the tapes out with the software releases to the government and colleges. Ran V6/V7 on Dec PDP-11, early PC-compatible stuff (maybe System II used? Can't recall for sure), 5B5/3B20 (AT&T designed hardware used when System III & V came available, IIRC) ... when a big HD was 10MB (or even 5MB) and memory was 64K and processors where 8086, 80186, 80286, ...
Everything was small, highly unreliable compared to today. HDs were sliced up to try and ensure minimal damage when the inevitable crash occurred. Backup process recommended was "Tower of Hanoi" strategy on tape (which were also limited in size). A thing called "speed" was non-existent compared to today. So another reason for slicing was to reduce fsck times.
The internet was not yet invented, but uucp and related provided "networking" capability.
I gave a one day class to some *very* smart folks at DARPA and you know what happened next - "internet".
Bill
Appreciate all the discussion, folks.
Got some boxes that have some separate / and /usr, since we're a /usr/local religion shop. (GRIN...) Someone long long ago, in a galaxy far, far away picked /usr as the split point, instead of /usr/local itself. So...
Layers 8 and 9 of the OSI model, bite again... Religion and Politics.
Guess we'll be moving to /opt or /usr/local being the separate mountpoint. I'm sure this will be a happy internal discussion... hahaha...
Nate
-
Fajar Priyanto -
Giles Coochey -
Gordon Messmer -
John R Pierce -
Les Mikesell -
m.roth＠5-cent.us -
Nate Duehr -
Nicolas Ross -
Paul Heinlein -
Stephen Harris -
Tilman Schmidt -
William L. Maltby