The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 27, 2012 0:10 UTC (Fri) by cantsin (guest, #4420)
Parent article: The case for the /usr merge

My understanding for having /bin, /lib, /var and /etc on root file system level and not in /usr was that absolutely essential OS tools could reside, if necessary, on a very small file system usable for all rescue scenarios, without the additional bloat of all the additional (but non-essential) software in /usr. This allows to put /usr on a separate disk. Even with today's disk capacities, this seems not a completely outmoded concept. It still makes sense, in many scenarios, to put all root directories on a small but fast SSD and /usr on a slower but bigger hard disk.

I wonder why one would throw out such a sane design.

to post comments

The case for the /usr merge

Posted Jan 27, 2012 0:26 UTC (Fri) by Karellen (subscriber, #67644) [Link] (92 responses)

From the Fedora project page[0] that Lennart's article is based off of and links to in the opening paragraph:

"You are doing it wrong! /bin and /sbin are there to rescue a broken /usr!

The most critical filesystem is /boot, because the kernel lives there. So the purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot). If either of them was broken, you were not able to rescue /usr. The role of the rescue system can easily be fulfilled by a rescue initramfs. So having the rescue initramfs in /boot, which contains the fsck utils, is in the same danger of becoming corrupted as the kernel. Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted."

[0] https://fedoraproject.org/wiki/Features/UsrMove

The case for the /usr merge

Posted Jan 27, 2012 0:40 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (91 responses)

More Lennart-speak:

The purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot).

1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

2. Even that aside, it's highly likely that two deliberately small, seldom modified filesystems will be available even if much-vaster, far more dynamic /usr cannot be mounted and must be repaired.

The role of the rescue system can easily be fulfilled by a rescue initramfs.

Yeah, thanks loads, Lennart. So, every time I have to maintain fsck, filesystem-diagnostic, backup/restore, etc. contents that would normally be in /bin, I have to rebuild an initramfs filesystem image. Swell.

For Pete's sake, stop trying to help, Lennart. (I remember he's been on this kick for a while with other justifications such as, paraphrasing, 'Binaries in /bin are often not even statically linked, or at least depend on libs inside /usr/lib.' Well, fix that, then.)

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 0:45 UTC (Fri) by sjj (guest, #2020) [Link] (8 responses)

You didn't RTFA, or you wouldn't be blaming Poettering.

The case for the /usr merge

Posted Jan 27, 2012 0:52 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (7 responses)

You are correct that I didn't RTFA attentively; haven't had time yet, and frankly I knew the inevitable bullshit arguments resting on prior bullshit arguments (regardless of whose they were) were just going to annoy me.

By the way: Congratulations on hitting the necessary sixty-second window before I was able to notice my error and post my regrets for having made it. You must be extremely proud.

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 3:51 UTC (Fri) by sjj (guest, #2020) [Link] (3 responses)

It was a simple factual correction. No need to get personal.

I just wish that people commenting on this site would try to be a little more thoughtful and not just assert "bullshit" based on their preconceived notions. Yes, I'm old fashioned and often disappointed.

The case for the /usr merge

Posted Jan 27, 2012 6:32 UTC (Fri) by dvdeug (guest, #10998) [Link] (2 responses)

No, "You didn't RTFA" is not a simple factual correction.

The case for the /usr merge

Posted Jan 27, 2012 16:04 UTC (Fri) by faassen (guest, #1676) [Link] (1 responses)

True, saying "my understanding of the article is different" or something along those lines would have been more polite, though less succinct.

The case for the /usr merge

Posted Jan 27, 2012 17:24 UTC (Fri) by sjj (guest, #2020) [Link]

Point taken. Argument by assertion just pushes my buttons.

The case for the /usr merge

Posted Jan 27, 2012 7:22 UTC (Fri) by hillman (guest, #82597) [Link]

Awesome comeback, you are definitely one of the sharper dudes here. I'm a /. refugee and your post warms my heart.

BTW, love the bullshit on your site, even if it is "(of historical interest, only)".

Peace out, bro.

The case for the /usr merge

Posted Jan 27, 2012 15:57 UTC (Fri) by faassen (guest, #1676) [Link]

You make it sound as if sjj magically should have known that you were going to come back and correct your error, and that it was very impolite of him to have done so before you did.

People correct each other not only because they're smartasses, but also for the benefit of others reading the discussion, and for guiding the discussion away from the wrong direction.

Perhaps you are proposing that before we correct anyone we should:

* check when this person was posting

* if it's less than a minute, wait a minute, check again whether they posted a correction

If so, I propose you lead by example. :)

The case for the /usr merge

Posted Jan 30, 2012 8:27 UTC (Mon) by sbergman27 (guest, #10767) [Link]

What is this "sixty-second window" you are talking about? I've never been able to correct even a minor speelling error after I click "Publish comment" on LWN.

The case for the /usr merge

Posted Jan 27, 2012 0:48 UTC (Fri) by Karellen (subscriber, #67644) [Link]

IT'S NOT LENNART-SPEAK! Lennart did not write the Fedora project page, or have anything to do with the writing of it. He only linked to it, tried to explain some parts which he thought were unclear, and then, just in case that wasn't clear enough, explicitly wrote that he didn't write the original, but wanted somewhere to point people when they wrongly assumed he had something to do with it!

Does no-one read the linked articles any more?

Hang on, I'm not on /. by mistake, am I?

The case for the /usr merge

Posted Jan 27, 2012 0:56 UTC (Fri) by motk (subscriber, #51120) [Link] (6 responses)

People still rely on static stuff in /bin for rescue work, rather than pxeboot or dc-monkey-boot a rescue image? How quaint!

The case for the /usr merge

Posted Jan 27, 2012 3:55 UTC (Fri) by sjj (guest, #2020) [Link] (5 responses)

Exactly. When did you last see a server that couldn't PXE boot? Workstations? Every distro has a live CD/USB nowadays.

The case for the /usr merge

Posted Jan 27, 2012 8:42 UTC (Fri) by petur (guest, #73362) [Link] (4 responses)

hint: embedded systems (will not boot from USB or CD)

The case for the /usr merge

Posted Jan 27, 2012 9:59 UTC (Fri) by hitmark (guest, #34609) [Link]

How about SD or similar?

The case for the /usr merge

Posted Jan 27, 2012 15:35 UTC (Fri) by the.wrong.christian (guest, #73127) [Link] (2 responses)

> hint: embedded systems (will not boot from USB or CD)

If your embedded system is borked, it's much more likely that you'd simply reflash the whole system, surely? An embedded system is not going to provide much of a recovery console to fix things.

The days of a 30MB / died with IRIX. Lets just move on.

The case for the /usr merge

Posted Jan 27, 2012 19:07 UTC (Fri) by xxiao (guest, #9631) [Link] (1 responses)

this is totally wrong, small embedded linux system is 1000X than those servers/desktops, and we design a recovery scheme to it.

The case for the /usr merge

Posted Jan 28, 2012 13:57 UTC (Sat) by HelloWorld (guest, #56129) [Link]

What do embedded systems have to do with this? You'd hardly install Fedora on an embedded system anyway.

The case for the /usr merge

Posted Jan 27, 2012 1:09 UTC (Fri) by josh (subscriber, #17465) [Link] (7 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Encrypted root filesystems, for one thing.

The case for the /usr merge

Posted Jan 27, 2012 1:53 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (5 responses)

Or a root filesystem on LVM, software RAID, or any other kind of complicated filesystem the bootloader can't understand. Although it looks as though GRUB2 is smart enough to get all those systems (including encrypted filesystems), so maybe separate /boot partitions are going to be as unnecessary as separate /bin, /sbin, and /lib directories.

The case for the /usr merge

Posted Jan 27, 2012 4:49 UTC (Fri) by jackb (guest, #41909) [Link] (2 responses)

Is it possible to install grub 2 on a hard drive that has a LUKS header instead of a partition table?

The case for the /usr merge

Posted Jan 27, 2012 9:54 UTC (Fri) by jengelh (subscriber, #33263) [Link]

There is no bootblock hole like there is on ext2, so the answer is no.

The case for the /usr merge

Posted Jan 30, 2012 19:13 UTC (Mon) by blitzkrieg3 (guest, #57873) [Link]

Not _instead_ of, but you could get grub to read your partition table and then read the luks volume inside the partition.

The case for the /usr merge

Posted Jan 27, 2012 9:01 UTC (Fri) by job (guest, #670) [Link] (1 responses)

I think it's much more common to utilize an initrd to boot from encrypted or DMed filesystems. At least all the normal distros do it that way.

The case for the /usr merge

Posted Jan 30, 2012 19:16 UTC (Mon) by blitzkrieg3 (guest, #57873) [Link]

Initrd and separate /boot are two separate things. You could have the initrd on a / file system in your /boot directory, as you can have a separate /boot partition that just tells linux to load / on another partition and execute /bin/init there.

The case for the /usr merge

Posted Jan 28, 2012 12:04 UTC (Sat) by gbrun (guest, #82611) [Link]

> Encrypted root filesystems, for one thing.

Yes. Another reason are special requirements for the boot loader itself.

For instance, I'm using ReiserFS for /. This FS employs "tail packing", i. e. there are cases when file data will be stored in units smaller than a full cluster ("sector").

File-system agnostic boot-loaders like LILO assume that all sectors in a block list have the same size, and therefore require ReiserFS volumes to be mounted with a special option which disables tail packing when updating the LILO configuration/mapping files.

But mounting ReiserFS with this option defeats its main advantage of space-efficiency for small files, so one does not generally want to do that.

As long as /boot is a separate small file system, this does not matter: One can either use ReiserFS for /boot and mount it with tail packing disabled, or use a different FS like ext2 there which only uses equally-sized clusters (this is what I do).

Also, the current FHS does not force anyone to put /boot onto a different partition - it's just an option.

Therefore, no matter where the basic discussion /bin vs. /usr/bin will eventually lead to, I strongly advise *not* to change the existing practice regarding /boot.

The case for the /usr merge

Posted Jan 27, 2012 1:18 UTC (Fri) by Wol (subscriber, #4433) [Link]

1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Because you've got a multi-boot system, and only have one copy of grub? Doesn't grub belong in /boot?

I've got a system that triple-boots - gentoo, suse and Windows. It helps if I keep all my boot stuff together.

Cheers,
Wol

The case for the /usr merge

Posted Jan 27, 2012 5:38 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Even that aside, it's highly likely that two deliberately small, seldom modified filesystems will be available even if much-vaster, far more dynamic /usr cannot be mounted and must be repaired.

The root filesystem is not seldom modified; in fact, until recently it was very difficult to avoid having to mount it read-write.

The case for the /usr merge

Posted Jan 27, 2012 20:01 UTC (Fri) by ttonino (guest, #4073) [Link]

I thought that /sbin and /usr/sbin were supposed to be the 'rescue' directories.

As far as I'm concerned, move everything to a central location (/usr/bin is fine) and keep statically linked _copies_ (or busybox) for rescue work.

That should keep that FS even more static and likely to be available. And package management will keep it up to date.

The case for the /usr merge

Posted Jan 27, 2012 6:28 UTC (Fri) by drag (guest, #31333) [Link] (5 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Yes. /boot.

The reasons you have /boot are for:

* Encrypted Root
* LVM
* File systems not supported by Grub
* Network boot
* Non bootable RAID devices (including software raid)
* Union file systems for /
etc etc.

How Linux works now is this:

Bios --> Executes boot loader
Grub --> Loads kernel + Initrd into ram and executes them

The purpose of having a /boot is to provide a platform for bootloader, of which Grub2 is one of many possible loaders, for boot strapping the kernel and initrd.

Initrd performs the necessary functions to get a root file system built up and configured correctly. Starts up software raid, mounts encrypted file systems, performs consistency checks, and can even provide for a emergency repair console if distributions choose to set it up that way.

The initial root file system in ram can perform all the necessary functions that originally having a separate / and /usr directory was meant to accomplish. Only now the 'kernel + initrd' is massively more robust and more flexible then a separate / ever was. Initrd is self contained, executes in ram, and can be loaded in dozens of different ways without breaking it and without it caring how it got loaded.

/boot is just the standard for boot strapping your system on x86 systems with a local hard drive. However there are many different ways it can be done.

A few commonly used examples:
* Load your kernel/initrd from PXE network boot
* Load it from a ISO with isolinux
* Load it from USB drive with syslinux
* Specify a abritrary kernel and initrd to be executed by Qemu/KVM via the command line or Libvirtd XML for launching virtual machines.

All sorts of stuff beyond that. Things that you could never, ever, pull off with trying to do a separate / partition, without massive headaches and all sorts of problems.

So not only has the most significant purposes of having a separate / file system have superseded by superior technologies, but having a separate / file system, for purposes of boot-strapping or rescuing the system, has been a fundamentally broken configuration for many years now. It's not just systemd or Lennart. It just isn't going to work well except in specific hand-crafted setups.

Try it for yourself sometime. Get rid of the initrd, make a custom kernel with everything you think you need, and try to boot / locally while mounting /usr over nfs. It can be done, but it's going to be a headache.

Seriously. I am surprised that somebody would think to try to defend a separate / while lambasting the idea that a separate /boot is necessary. If anything it would make more sense to try to use /boot to help defend the idea that preserving the ability to use a separate / would be necessary.

> Yeah, thanks loads, Lennart. So, every time I have to maintain fsck, filesystem-diagnostic, backup/restore, etc. contents that would normally be in /bin, I have to rebuild an initramfs filesystem image. Swell.

I don't know why you are thanking Lennart. You should be thanking hundreds, if not thousands of people, who put about 20 years of Linux operating system development into practice.

Have you not noticed that when ever you perform a significant system update on you rebuild your initrd? When you install lvm tools, or software raid stuff, or encrypted file system support that this usually causes your initrd to be be rebuilt. It's been like that for a long time.

The case for the /usr merge

Posted Jan 31, 2012 16:38 UTC (Tue) by wookey (guest, #5501) [Link] (4 responses)

This is a very x86 PC-centric view. It is not 'how Linux works' in a more general sense. Other hardware boots in various other ways, not involving BIOS or GRUB, and may or may not have an initrd.

An initrd slows things down quite significantly which is a big deal for some use cases. It provides great advantages in terms of single-boot-image generality and ease-of-rescue but also a cost in speed (and size, although that's small these days at ~2-10 Mb compressed). Boot speed and image generality tend to be in direct competition.

And to answer another post further up, plenty of 'fairly embedded' machines provide a (serial or USB or LCD) console though which rescue can be done and you don't simply want to re-flash and (for example) lose 3 years of logging data. I am thinking of the balloon board controlling my heating system in this case.

Whether overall, moving everything to /usr is a good plan remains to be seen. Personally I am skeptical but I have only spent a limited amount of time reading about the implications so far.

The case for the /usr merge

Posted Jan 31, 2012 17:36 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

In the common case where /usr is not its own filesystem then it's a simplifying cleanup and a noop for reliability and where /usr is a separate filesystem then making sure you have to tools to mount it in initrd, same as you already need tools to mount the root filesystem. Basically its simpler to make sure the appropriate tools are available in an initrd, which only needs a working bootloader to load, than to limit the design of the system so that the rootfs and /usr must be available without tools to set them up. If you already have an initrd then duplicating that functionality in the root filesystem isn't necessary and if you don't have an initrd then the root filesystem and /usr need to be mountable by the bare kernel without tools.

Is any of that a good explanation?

The case for the /usr merge

Posted Jan 31, 2012 21:44 UTC (Tue) by wookey (guest, #5501) [Link]

Yes, thank you. Put like that I can't see any reason to object to it.

Now lets see what I think after reading the other 250(!) comments...

The case for the /usr merge

Posted Feb 2, 2012 5:44 UTC (Thu) by thedevil (guest, #32913) [Link] (1 responses)

"if you don't have an initrd then the root filesystem and /usr need to
be mountable by the bare kernel without tools"

'Scuse me, I don't follow this part. / yes, /usr no. They can be very
different, after all, /usr can be a network filesystem or more generally
just require a kernel module to mount. Isn't that what the whole debate
is about?

The case for the /usr merge

Posted Feb 2, 2012 7:06 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The point is that the initrd is the appropriate place to put those tools as it can be reliably loaded using he same method as he kernel. You could have a root filesystem that requires a module or network mount so you already need to support this kind of complexity in the initrd. If you don't want an initrd for some reason then this naturally limits the filesystem setup you can boot off of.

The problem with maintaining a split system is that it is currently broken on the major systems and has been for some time. At least a dozen binaries in the base system depend on resources in /usr. Fixing it by moving more of the system into the root directories seems more complex and prone to breakage than relying on the toolkit in initrd. Since all the tools you need are already in the initrd, maintining the /sbin /usr/sbin split doesn't have a point. Getting rid of the split makes the system simpler and more flexible so it seems like the right choice

The case for the /usr merge

Posted Jan 28, 2012 1:27 UTC (Sat) by sbergman27 (guest, #10767) [Link] (37 responses)

"1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)"

For whatever reason, a separate /boot filesystem is necessary to convince RHEL's Anaconda to install grub on /dev/md0 rather than /dev/sda. Red Hat says a separate /boot is necessary to boot off software RAID.

Amusingly, that advice about "older systems" is still alive and well in 2012. New users worry about it since their machine is one of those older Core2 Quad systems and not a modern Core i7.

Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?

The case for the /usr merge

Posted Jan 28, 2012 15:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (36 responses)

> Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?
You're clearly confused. Both PulseAudio and systemd are massive improvements.

The case for the /usr merge

Posted Jan 28, 2012 23:28 UTC (Sat) by sbergman27 (guest, #10767) [Link] (35 responses)

I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another. I've also never had one where Pulse brought with it any advantages. Per app volume controls? What apps don't have thier own? Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels? Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.

Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.

Mark my words. Fedora will be changing its init system again in the not so terribly distant future. After they've had enough of Lennart and systemd, and something newer and shinier comes along.

-Steve

The case for the /usr merge

Posted Jan 28, 2012 23:53 UTC (Sat) by HelloWorld (guest, #56129) [Link] (12 responses)

> I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another.
This is the typical FUD of lwn trolls. How many machines did you try it on? When was that? What specific problems did you run into? Without this kind of information, a comment like yours is just useless trolling.
Anyway, I've been using PulseAudio for some time now and it works flawlessly.

> Per app volume controls? What apps don't have thier own?
Firefox doesn't and I don't know how to use mplayer's. And I don't feel like I should need to learn, after all, pavucontrol offers a consistent interface for *all* sound applications.

> Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels?
Err, like, almost every one? I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke. That's because hardware mixing is useless nowadays.

> Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.
It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs.

> Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.
This is, again, totally useless. Where's your source? I checked netsplit.com and couldn't find anything about these supposed problems.

The case for the /usr merge

Posted Jan 29, 2012 2:58 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

"This is the typical FUD of lwn trolls."

I don't intend to spend the evening flame-warring with you. However, I will respond exactly once.

I've used it on many machines (too many to remember or count) since it first debuted in Fedora... whatever it was. 7? And I'm not kidding. There has always been *some* problem that prompted me to uninstall it. The first time through it immediately locked up all the remote X desktops at the client site where I had done the upgrade that introduced PA. And the problems continued, year after year.

Granted, over the last year or two I've taken to just uninstalling it immediately after installation. I did not do so on my new Scientific Linux 6.1 desktop... and sound in totem-plugin didn't work at all... until I uninstalled pulse.

"Firefox doesn't and I don't know how to use mplayer's"

Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer. I can't say as I've noticed the Firefox issue since there is so little HTML5 streaming media available now. There's Youtube HTML5 beta. But it still doesn't work well enough to use on an every day basis.

"I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke."

What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

"It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs."

And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

"This is, again, totally useless. Where's your source?"

That information came from a talk given by Scott. It's available online. I spent a bit of time looking for it. But like I say, I'm not about to waste excessive time this evening arguing with an obvious Poettering fanboy over trivialities.

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 10:11 UTC (Sun) by niner (guest, #26151) [Link] (9 responses)

> Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer.

The only thing that MPlayer does is control the PCM volume. So when you turn down the volume in MPlayer, everything else gets quiet as well. That's hardly what I would call per application volume control.

> What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case.

> And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

Because PulseAudio tries to do something better than sound systems on Linux have before. It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups. Just like for example OS X has been able to for years.

The case for the /usr merge

Posted Jan 29, 2012 11:12 UTC (Sun) by mikachu (guest, #5333) [Link] (4 responses)

echo softvol = yes >> ~/.mplayer/config

The case for the /usr merge

Posted Jan 29, 2012 11:32 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

Which raises the inevitable question "Who, exactly, thought that softvol=no being the default was a good idea?".

The case for the /usr merge

Posted Jan 29, 2012 13:43 UTC (Sun) by mastro (guest, #72665) [Link]

Softvol uses a bit more CPU and when used at very low volume degrades sound quality when compared with just setting the correct PCM volume. At least this was the case a few years ago, not sure how stuff works with pulseaudio.

The case for the /usr merge

Posted Jan 29, 2012 13:58 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

Why bother with editing config files, when I can just use pavucontrol which gets the job done and works the same everywhere?

The case for the /usr merge

Posted Jan 30, 2012 20:18 UTC (Mon) by mikachu (guest, #5333) [Link]

I was just correcting an incorrect statement, feel free to use whatever you want.

The case for the /usr merge

Posted Jan 29, 2012 17:06 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case."

Even better. Then Pulse is not only redundant, but in some cases double-redundant.

"It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups."

Show me the data. I'm extremely skeptical. Unless you mean that you save a lot of power after your sound dies. That would make sense.

The case for the /usr merge

Posted Jan 30, 2012 1:40 UTC (Mon) by slashdot (guest, #22014) [Link] (2 responses)

dmix won't be enabled if Pulse is active, in sane distributions, obviously.

The case for the /usr merge

Posted Jan 30, 2012 19:40 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

But ALSA will be there. (Is anyone using OSS?) So PA's "functionality" is still redundant in this capacity.

The case for the /usr merge

Posted Feb 2, 2012 8:54 UTC (Thu) by keeperofdakeys (guest, #82635) [Link]

ALSA is incapable of software mixing, the dmix plugin handles this. So PA isn't redundant in this capacity.

As for OSS, no one uses it directly (or at least shouldn't). Many programs will use the OSS emulation offered by ALSA (which doesn't support software mixing). The interesting thing about OSS is that it was originally open source, became closed, and became open source again with version 4. Although, now we have shifted to ALSA, it will probably never be as popular.

The case for the /usr merge

Posted Jan 31, 2012 10:37 UTC (Tue) by daniels (subscriber, #16193) [Link]

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

It's a shame that this approach doesn't extend to LWN comments too.

The case for the /usr merge

Posted Jan 29, 2012 5:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

Last time you made a bet against Fedora, you lost but you probably don't remember that. So I am curious. What's the timeframe and what do you promise to do if you lose your bet? :-)

The case for the /usr merge

Posted Jan 29, 2012 5:48 UTC (Sun) by sbergman27 (guest, #10767) [Link] (20 responses)

"What's the timeframe and what do you promise to do if you lose your bet?"

It depends upon when the next new and shiny comes down the pike. One thing you guys can never seem to resist is new and shiny. Sometimes my Fedora predictions turn out to be correct. And sometimes they don't. To which one are you referring?

I'll sincerely give you credit, though. In general, the churning nightmare that is Fedora, after being vetted, tested, filtered, beta'd, properly QA'd and released by your parent organization, is absolutely top notch. Oh, RHEL's PulseAudio is nearly as bad as it was in Fedora, as I have already described. But it's easily removed. And packagekit inherits the perrenial locking problems that yum has had since the FC1 days. And it's still slower than Synaptic. (Although better than it used to be.) But other than that, RHEL and its clones are absolutely fantastic. I've taken a hiatus from Ubuntu on my home desktop, and am quite enjoying RHEL, CentOS, and SL. Especially SL, which is a new one for me.

Not that I ever left the RHEL family behind. It is a bitter-sweet combination of sadness and joy to me that several of my customers' venerable CentOS 4 servers must be upgraded in the next month. It's been a great 7 years of perfect OS stability. Some will be going CentOS 6.2. Others to Scientific Linux 6.1, or 6.2 if it is ready.

Oh, what the hell. I predict you'll be off systemd in 3 years or I'll buy you a burger. We can sync up in 2015. :-)

-Steve

The case for the /usr merge

Posted Jan 29, 2012 15:59 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (19 responses)

Nah. No burger. You will lose the bet and when you do, if you can sing praises of Fedora all the time, we have a real wager. See you in 2015.

The case for the /usr merge

Posted Jan 29, 2012 17:50 UTC (Sun) by sbergman27 (guest, #10767) [Link] (18 responses)

"You will lose the bet and when you do"

Time will tell. Your last new init replacement didn't lask very long in the very fickle Fedora. Few things do. So the odds are in my favor.

"if you can sing praises of Fedora all the time,"

Highly unlikely, but not entirely beyond the pale. It depends upon how responsibly the Fedora devs and advocates behave in future. I'm am critical. Even biased by long experience with the distro. But I am also fair.

BTW, my memory may be somewhat better than you counted on. I distinctly remember you stating that you had lost all respect for me because you felt that I was blaming Fedora for that Fedora creation, Pulse Audio, causing widespread problems in other distros. You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back.

Well... I now have 3 Scientific Linux 6.1 machines within 1 meter of me which put the lie to that claim. Unless you want to claim that Fermilab and Cern took the perfectly functional PA from Red Hat's premier OS, RHEL 6, based upon F12 and F13, and broke it, I must conclude that PA in F12 and F13 was as broken as I claimed at the time. Sound randomly dies on all three of these machines (with 2 different audio chipsets) until PA is removed. That, after an additional 3 years of QA from Red Hat, which normally does do well.

I really should have bet you a nice lobster dinner on *that* one.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 18:09 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (12 responses)

My instinctive questions would be "How large a sample size is two audio chipsets?" (I have no particular feel for how many different audio chipsets exists) and "Which audio chipsets, and did you file a bug report or just go 'bah, poxy lennartware *uninstall*' and not bother?".

The case for the /usr merge

Posted Jan 29, 2012 20:22 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

It's been admitted in this very thread that PA tries to do things that have worked for Apple on its tightly controlled harware, but apparently don't work well in the freewheeling world of PC hardware. That was a fatal design in PA for its intended audience.

Vendors of sound hardware don't care if PA works or not. And with Linux having been stuck at ~1% of the desktop market for the last 10 years, that situation is not likely to change. Best to deal with sound hardware the way it *is* and not the way you'd like it to be.

ALSA FTW! The pragmatic approach is often the best.

-Steve

You've started it...

Posted Jan 29, 2012 21:34 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.

ALSA FTW! The pragmatic approach is often the best.

Right. And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID. This reduces amount of testing required - which is practical for me. Systems with uninstalled PulseAudio most definitely fit the bill as far as sound is involved.

You've started it...

Posted Jan 29, 2012 21:40 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID.

Right. So in the end nobody but the developers can use the configuration options provided, because if they use them they can't report bugs or get them fixed. And then those configuration options get removed because they're unused. And then we look around at the non-configurable desert which our free platform has become and wonder when exactly we took this wrong turn.

You've started it...

Posted Jan 30, 2012 9:56 UTC (Mon) by khim (subscriber, #9252) [Link]

Why do you think someone took the wrong turn? Non-configurable desert is one description which tries to imply this is somehow bad. Uniform experience is another description for the same thing - and it's usually praised by reviewers... unless they themselves want to change something - and can not.

I'm not saying all options are worthless (it'll be hypocritical for me to say so since I toggle quite a few knobs on new systems). But they should all earn the right to live. No exceptions. You must compare overhead the developer faces for given option with popularity of said option. If option is wildly popular then it must be supported even if it's quite painful for the developer. If it's trivial and does not require a lot of Q&A resources then it can be kept even if it's not all that popular. But if it's both not popular and painful - then it's better to make it go away.

You've started it...

Posted Jan 29, 2012 22:05 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.
"""

44 million. But since PA depends upon the underlying sound system, if one's chances of getting sound working in Linux without PA are bad, their chances of getting it working with PA are far worse.

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish. No, that's not right. At this point, in 2012, it's pretty certain that Desktop Linux has always had a deathwish. We never had a chance. We only kill the things we love.

You've started it...

Posted Jan 30, 2012 9:49 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish.

Sorry, but you are wrong again. Try the aforementioned search with esd instead of pulseaudio or alsa - and you'll get more results then in pulseaudio case.

The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd.

You've started it...

Posted Jan 30, 2012 14:48 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Even better than ESD, remember ARtS? Why have one sound server when you have have two incompatible ones both vying for access to a single, exclusive, sound output along with applications who try to use the sound output directly. Having one sound server rather than a bunch of incompatible ones fall in an out of fashion every few years is an improvement in and of itself, even if it was no better, which it is.

You've started it...

Posted Jan 30, 2012 19:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd."

I only use a sound server when such functionality is useful. i.e. network transparency. (Though HelloWorld has mentioned another feature useful for some.)

You don't seem to understand that the sound server is dependent upon the underlying sound system on either the client or the server machine.

I've had less trouble (in fact, no trouble) with ESD. But I don't use any sound server when none is required.

The case for the /usr merge

Posted Jan 29, 2012 21:43 UTC (Sun) by elanthis (guest, #6227) [Link] (1 responses)

> Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before. Also, ALSA/ESD don't support device hot plugging with automatic output switching, which I do use here and there on my laptop.

Anecdotes are a GREAT way to debate!</sarcasm>

The case for the /usr merge

Posted Jan 29, 2012 22:50 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"""
My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before.
"""

Obviously, that was a problem with your configuration or harware.

(That's a little joke. But do try the latest ESD nightlies! They're fantastic!)

I quite agree with you about anecdotal evidence. Unfortunately, it's pretty much all we have in Desktop Linux. Rightly or wrongly, one's own anecdotes take priority over others' anecdotes. And there is some justification for that. About all we can do right now is keep careful notes and do the best we can with the information we have, trying to keep in mind the 'p' significance of our own personal datasets.

It would be much nicer to have actual data. But indeed, the plural of "anecdote" is not "data".

On my machines, and my customers' machines, over the last serval years, PA has been pretty much a failure.

The case for the /usr merge

Posted Jan 30, 2012 2:07 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

> But why bother when it offers no advantage to just using ALSA?
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets). Anyway, you're obviously biased against PulseAudio, so discussing this with you is probably a waste of time.

The case for the /usr merge

Posted Jan 30, 2012 7:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets).
"""

That's a reasonable enough point. It's not one that interests me. But it is likely significant to others. I would have nothing against PA if it did not so often break sound completely. If it sometimes allows people to enjoy a degree of increased flexibility, I would not begrudge them that.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 0:57 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

"You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back."

This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all. So yes, my memory is much better than yours. We will see you in 2015 when you lose your bet :-)

The case for the /usr merge

Posted Jan 30, 2012 7:04 UTC (Mon) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all.
"""

It was either here or on OSNews. I might even bother to look it up if there were a lobster dinner in it for me. Just kidding on that last. Lobster is... tedious. But it *was* either here or on OSNews. And I'm not kidding on that point. :-)

-Steve

The case for the /usr merge

Posted Jan 30, 2012 15:40 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I am sticking to my bet. You can't provide a direct quote.

The case for the /usr merge

Posted Jan 30, 2012 20:42 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

It's not important enough to go digging through the archives for. I suspect you do remember it. I do, since it was the first response which I had seen from you in which you seemed to have lost your cool. It made me wonder if I had, perhaps, pushed things too far.

If so, I belatedly apologize. We do spar. But know that I do value your contributions, and respect your convictions. (In case you didn't already know.)

I still dislike Fedora. But it results in RHEL, which is superb. Hey, most people don't think of the stinking draught of the slaughter house when they go to Wendy's for a burger. I don't think of Fedora when I use Scientific Linux or CentOS.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 21:13 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

People putting words on my mouth is a pet peeve of my mine but I do remember clearly what I said and you are badly paraphrasing it, which is what I was hinting at strongly. Feel free to look up the archives if you want to confirm what I said.

IMO, it doesn't make sense to look down on a parent distribution while praising a derivative when the benefits you see on the derivative are the direct result of a lot of the work in the parent. This applies as much to Fedora and RHEL and in many even more so when compared to say Debian and derivatives. In other words, work done in Fedora is a necessity for the results you see in RHEL and rest of the Linux world. Fedora might not be suitable for you and I understand that. However the evident disdain is irrational and just seems like a sore gripe from the past, be it Fedora or PulseAudio considering for instance, majority of distributions seem to be defaulting to it and I don't think most people are having any issues anymore. I would say, time to let go and move on to whatever works best.

The case for the /usr merge

Posted Jan 28, 2012 5:04 UTC (Sat) by jimparis (guest, #38647) [Link] (16 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

And the 2TiB limit came up to take its place. I'm glad that separate /boot is still so well supported. I have a system with 3 TB drives, but the BIOS only recognizes and boots from MBR partition tables. I need a /boot partition entirely contained within the first 2 TiB, and then a GPT containing the actual partitions for Linux.

The case for the /usr merge

Posted Jan 29, 2012 13:51 UTC (Sun) by mastro (guest, #72665) [Link] (15 responses)

This sounds like a bootloader limitation, AFAIK the BIOS just reads and executes the first sector if it has a two-byte magic signature, even if it's not a MBR.

The case for the /usr merge

Posted Jan 29, 2012 18:08 UTC (Sun) by jimparis (guest, #38647) [Link] (14 responses)

In a way, yeah, it is a bootloader limitation -- GRUB is still using BIOS to read sectors off the disk, so it can only ask for sectors within the first 2 TiB. GRUB does have an (incomplete) ATA driver that can work in some cases, and that driver support could be improved, but there's no way you're going to fit all those drivers into the first 512 byte sector, so there will necessarily still be BIOS calls to read more sectors from the disk. And since those sectors need to be below 2 TiB, you're limited to either playing tricks (like cramming your drivers into empty alignment space before your real partitions) or something a bit cleaner (like giving it a real /boot partition, in which case you can keep using the BIOS calls for loading the kernel and initrd too).

The case for the /usr merge

Posted Jan 29, 2012 20:33 UTC (Sun) by sbergman27 (guest, #10767) [Link] (12 responses)

We take these things as being "normal". But sometimes newbies say the darndest things. A while back, I had one ask me the question (paraphrased) "We know from long experience that hardware capabilities are increasing geometrically. And we have a good idea what that geometric rate is. Why don't they just build computers and software accordingly?". And I've got to admit, he had a point.

I've already had enough of dealing with silly "limits" to last a lifetime. Current rate of change doesn't matter. It's the first derivative that does. The second has always remained remarkably close to 0. :-)

-Steve

The case for the /usr merge

Posted Jan 29, 2012 23:03 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (11 responses)

I suspect that the problem is not with software authors not understanding the speed of hardware development, but with them underestimating the lifespan of their projects. They assume that their project will have a limited lifespan, so they take shortcuts that will make their work easier but cause problems in a predictable but seemingly long time. What they are forgetting is that sensible people don't replace working infrastructure just for fun, so their design is very likely to remain in use until one of those arbitrary limits is hit.

The case for the /usr merge

Posted Jan 30, 2012 0:01 UTC (Mon) by sbergman27 (guest, #10767) [Link] (10 responses)

"I suspect that the problem is not with software authors not understanding the speed of hardware development, but with them underestimating the lifespan of their projects."

Of course, it's also to IHV's advantage for their hardware to become obsolete in a few years. After all, how were they to know that hard drives would increase in size so fast?

Today, they are happy to sell you a new system that is 100x more powerful, which will do for you... about as much as your old system did.

A permanent state of hyperinflation which people are so used to that they hardly notice that they are on a treadmill. Fundamentally, there is less reason to replace their computers than to replace their cars.

Computers generally don't wear out. Except for hard drives. And if the new drive won't work with your old machine, planned obsolescence wins again.

And the "ka-ching!" sound of the cash register rings again at Dell, or HP, or Acer.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 3:15 UTC (Mon) by raven667 (subscriber, #5198) [Link] (9 responses)

One thing that does make a difference is "fuel efficiency", the resource savings on a new computer paired with consolidation often more than pays for the cost of new hardware. The funny thing is that the benefits of fuel efficiency in cars is often overrated, the cost of a new car or the difference in price between a Prius and a 20mpg car is not going to be made up by fuel savings over the average lifetime of the car

The case for the /usr merge

Posted Jan 30, 2012 8:17 UTC (Mon) by sbergman27 (guest, #10767) [Link] (8 responses)

The fuel savings between a Prius and a 20mpg car in the US works out to about $9000 over 150,000 miles. I'm not sure what to put in for a car's "lifetime". Mine have 160,000 - 380,000 miles on them, currently. And range from 24 to 45 years old. I don't think that's typical. The one with the 380,000 miles on it is my 1988 Chevy Sprint Metro. (Really a rebadged Suzuki.) It beats the Prius, with an original 55mpg city/60mpg highway EPA rating. The 2008 adjusted numbers being 44mpg city/51mpg highway. (In which case it only beats the Prius on the highway.)

The Sprint has saved me over $30,000 in fuel cost over its lifetime, compared to the 20mpg car you suggest for comparison. Not including the avoided cost of buying new cars to replace it. (Suzuki reliability was amazing.)

The "advantage" to throwing away old computers and replacing them with new, more fuel efficient ones has always seemed a bit iffy to me. I support the practice. But I'm not sure it makes economic sence based solely upon electricity savings.

On an absolute scale, looking at fossil fuel usage kilogram for kilogram, more efficient cars are clearly more important than more efficient computers.

The case for the /usr merge

Posted Jan 30, 2012 14:43 UTC (Mon) by raven667 (subscriber, #5198) [Link] (7 responses)

I would put 100k-150k for a lifetime of a car, most people don't hold on to them even that long. In the Prius case that's not even including the cost of replacing the battery packs which I would expect to wear out in that time frame. So at best you have 10k savings, probably less, which means that keeping an older car and putting more miles on it (taking it past 150k like your cars) is probably more energy efficient than building/buying a new one every couple of years just to take advantage of a 5-15mpg difference.

This is different than computers as they are both getting more energy efficient _and_ more capable leading to consolidation in addition to the per CPU core power savings so it's more like a 20:1 efficiency improvement, actually 40:1 because you usually spend as much in cooling as in power usage. A 20 yr old car only has minor capability differences with a modern, high efficiency car.

The case for the /usr merge

Posted Jan 30, 2012 18:28 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

I have seen capacity growing at the rates that you are talking about, but not energy efficiency.

do you have pointers to the efficency claims for capacity/power savings growing that significantly?

the other issue is that electricity is pretty cheap, so it takes a LOT of power savings to equal the cost of a new server.

The case for the /usr merge

Posted Jan 30, 2012 20:12 UTC (Mon) by raven667 (subscriber, #5198) [Link] (2 responses)

The efficiency is that you can run an 8 or 12 core machine with 64-128GB RAM using the same power as a 2 core machine with 4-8G RAM from 5 years ago. Power needs per CPU core are dropping. That trend coupled with virtualization allows you to get more out of you new hardware purchase, consolidating 20:1 on servers and 40:1 on power to run the same workload, and giving plenty of breathing room for your facilities for growth. Having a datacenter run out of power/cooling is very expensive.

The case for the /usr merge

Posted Jan 30, 2012 20:30 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

consolidating 20:1 on servers is fantastic, my company is going heavily into vitualization and is only seeing about 3:1 so far (with the target being 6:1)

also, this sort of savings from virtualization assumes that you are running your prior servers lightly loaded. If you have an application that is large enough that you need to run it on multiple machines to start with, virtualization is a net loss (although this net loss is frequently covered by by doing the consolidation at the same time as a server upgrade)

I don't know about your servers, but on the ones I am seeing 8-12 cores with 64-128G of ram takes significantly more power than the 2-core servers with 4-8G of ram that I still have in production. measurements show somewhere between 2x and 3x

The case for the /usr merge

Posted Jan 30, 2012 21:06 UTC (Mon) by sbergman27 (guest, #10767) [Link]

This reminds me of that great TV commercial IBM did several years ago. "They've stolen the servers! They've stolen the servers!"

The Heist: http://www.youtube.com/watch?v=T-NpLu2xC38

-Steve

The case for the /usr merge

Posted Jan 30, 2012 20:10 UTC (Mon) by sbergman27 (guest, #10767) [Link] (2 responses)

"I would put 100k-150k for a lifetime of a car, most people don't hold on to them even that long."

That's quite a different thing than the lifetime of the car. It gets sold to someone else. Pick up an Autotrader mini-mag sometime. Basically, a classifieds specializing in used cars. Not classics, necessarily. Just used cars. 200,000+ miles is not in the least uncommon.

And I. too, would be interested in your data supporting your claim of such amazing efficiency improvements in computers.

Also, while I have your ear, and in reference to another thread, I would be interested in your explanation as to why the Linux i/o schedulers would not sort the read/write requests of a random access benchmark to provide *far* better performance than the 6ms per request then you seem to agree with Dave about. Even the noop scheduler does elevator sorting of requests. For that matter, so does the drive's internal cache.

If you do not understand one or more of those terms, let me know and I will explain them to you.

The case for the /usr merge

Posted Jan 30, 2012 21:08 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

I did some googling and came up with some representative links. The take-away is that each new generation of machines for the last 5 years or so has relatively the same or slightly higher power consumption but we went from dual single-core to dual dual-core to dual quad-core and dual hex-core without doubling, quadrupling, octupling power usage. All that power not generating heat also takes a load off cooling which is more power savings.

http://www.networkjack.info/blog/2007/02/13/power-consump...
http://www.utahsysadmin.com/2007/04/19/power-requirements...

http://www.dell.com/us/dfb/p/poweredge-1950/pd
http://www.dell.com/us/business/p/poweredge-r610/pd

As far as IO schedulers, elevators help but are no panacea. I think the estimate of 175 IOPS on a 7.2k RPM drive is about right. A 15k RPM drive may get you close to 250 IOPS but that's the limit of spinning rust. An average seek time of 6ms doesn't seem out of whack, it actually sounds pretty good. With perfect elevators if the data isn't immediately adjacent then there is going to be some number of milliseconds of track to track seek time for every IO. The longer IO is delayed so that it can be sorted the more latency is added onto all the requests. In any event a random IO test is going to be the worst possible case for an elevator algorithm.

For example here are the results of a naive model where one has 65535 tracks and a linear track to track seek cost. The first table is random and the second has been sorted by an elevator. In practice with disks there is always an elevator in the drive, in the drive controller, in the OS so you will never see the first access pattern and more sorting isn't going to make the second pattern any better.

More info on actual drive characteristics for better modeling

http://en.wikipedia.org/wiki/Disk-drive_performance_chara...

request address seek
1 62640 #VALUE!
2 34681 27959
3 21062 13619
4 39674 18612
5 46138 6464
6 42942 3196
7 3227 39715
8 25600 22373
9 62505 36905
10 18344 44161

Total 213004

request address seek
7 3227 #VALUE!
10 18344 15117
3 21062 2718
8 25600 4538
2 34681 9081
4 39674 4993
6 42942 3268
5 46138 3196
9 62505 16367
1 62640 135

Total 59413

The case for the /usr merge

Posted Jan 30, 2012 21:16 UTC (Mon) by sbergman27 (guest, #10767) [Link]

Let's move this back to the XFS thread.

The case for the /usr merge

Posted Jan 30, 2012 1:44 UTC (Mon) by slashdot (guest, #22014) [Link]

<<
The current 48-bit LBA scheme, introduced in 2003 with ATA-6 standard, allows addressing up to 128 PiB. Current PC-Compatible computers support INT 13H Extensions, which use 64-bit structures for LBA addressing and should encompass any future extension of LBA addressing, though modern operating systems implement direct disk access and do not use the BIOS subsystems, except at boot load time. However, the common DOS style Master boot record partition table only supports disk partitions up to 2 TiB in size. For large partitions this needs to be replaced by another scheme for instance the GUID Partition Table which has the same 64-bit limit as the current INT 13H Extensions.
>>

The limit is in the MBR format and/or BIOS implementation.

The case for the /usr merge

Posted Jan 30, 2012 23:03 UTC (Mon) by ondrej (subscriber, #27872) [Link] (1 responses)

> 'Binaries in /bin are often not even statically linked, or at least depend on libs inside /usr/lib.'

JFTR On my Debian stable system:
$ ls -1 /bin | wc -l
104
$ ls -1 /bin | xargs -i ldd {} | grep /usr
/bin/ping6
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f88fc791000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f88fc014000)

$ ls -1 /sbin| wc -l
182
$ ls -1 /sbin | xargs -i sh -c 'echo {}; ldd {}' | grep /usr -B10
fsck.cramfs
libz.so.1 => /usr/lib/libz.so.1 (0x00007f48dc0a2000)
mkfs.cramfs
libz.so.1 => /usr/lib/libz.so.1 (0x00007f478f0cb000)
mkfs.ntfs
libntfs.so.10 => /usr/lib/libntfs.so.10 (0x00007f4208125000)
mount.ntfs-fuse
libntfs.so.10 => /usr/lib/libntfs.so.10 (0x00007f02a6a86000)
libfuse.so.2 => /usr/lib/libfuse.so.2 (0x00007f02a6851000)
nfnl_osf
libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x00007f1af01b8000)
umount.udisks
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007fc7b1575000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fc7b1111000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007fc7b068f000)

Not that bad, isn't it?

The case for the /usr merge

Posted Feb 2, 2012 13:01 UTC (Thu) by Comet (guest, #11646) [Link]

FreeBSD and using *(.) in zsh to avoid the compatibility symlinks I've added for a couple of shells, not needed for booting:

% ls -1 /bin/*(.) | wc -l
41
% ls -1 /bin/*(.) | gxargs -i ldd {} | grep /usr
%

Use *(-.) to include the symlinks and there's output.

Myself, I use a separate / from /usr and /var because while / may need to be mounted read-write, it needs far fewer writes than the other areas. This means that in the event of a system crash it is less likely that there was I/O pending to / and increases the odds of my booting without having to sort out recovery options, just being able to repair and move on.

That applies no matter which OS. It has helped when some neighbours in a building with bad wiring were able to trip our fuses and rebooted my Linux box often enough before I bought a UPS. That helped me get up enough connectivity in those pre-bootable-USB-recoverydisk days to be able to make a CD backup of the stuff I could recover from a corrupted ReiserFS before reinstalling with ext3. Without a second CD drive or the money for a second computer, that would have been notably more awkward.

Some habits save your butt often enough that it is going to take a *lot* to convince folks like me that the latest shiny shiny is worth surrendering a practice which has proven its worth repeatedly.

The case for the /usr merge

Posted Jan 27, 2012 0:42 UTC (Fri) by sjj (guest, #2020) [Link]

It makes a lot of sense. Read the myth/fact part.

On a production RHEL5 server I have this:
$ du -sh /sbin /usr/sbin /bin /usr/bin /lib /usr/lib /lib64 /usr/lib64
38M /sbin
26M /usr/sbin
8.4M /bin
113M /usr/bin
130M /lib
440M /usr/lib
27M /lib64
339M /usr/lib64

$ du -sh /usr
2.2G /usr

I don't think you're going to find an SSD *smaller* than this, so why not just put everything on the same filesystem. Even on my Fedora desktop box (that I don't have access to right now), I don't think / and /usr are more than 15 GB together.

The split is from the era when hard drive sizes were measured in megabytes, not giga- or terabytes.

The case for the /usr merge

Posted Jan 27, 2012 0:42 UTC (Fri) by tchernobog (subscriber, #73595) [Link] (3 responses)

As explained in the article, booting without a /usr has been broken for years. That kind of support nowadays goes into a ~12MB initramfs. It won't be fixed even without the /usr move, as the initramfs + busybox and friends works well enough.

The idea of having /usr containing everything a system might want after booting (in terms of shared resources) is better, especially if you want to share it as a network filesystem or mount different guest systems using the same kernel.

For instance, to keep updated a distributed environment like a university lab you wouldn't have to care if running an update writes in /usr/bin (only one instance in the network, you update it centrally) or in /bin (changes need to be propagated manually).

Having /var and /etc in the root is because they offer different assets than /usr: they are machine-specific: each machine has its own version with its own configuration and spool directories (think of /var/mail). Binaries and shared files instead pertain to /usr.

Incidentally, if you were to put the whole /usr on a slower disk, considering 90% of libraries in use by a running system are in /usr/lib(64) and executables are in /usr, you wouldn't perceive much of a difference in performance. You'd waste your money on a SSD then. If you want to check, just try opening the normal applications you use (I don't know: firefox, evolution, libreoffice...) and run:

sudo lsof | awk '$9 ~ /^\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l
sudo lsof | awk '$9 ~ /^\/usr\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l

This actually doesn't tell you the whole story, because it should be seen also how many files are read at application startup from other directories such as /usr/share (all icons, desktop files, resources, databases, etc.). That bumps up the number considerably.

The case for the /usr merge

Posted Jan 27, 2012 2:06 UTC (Fri) by fest3er (guest, #60379) [Link]

For most desktop/server systems, there's little reason not to build the standard initramfs to contain everything needed to explore and repair a broken system. I did this, at least partly, with Roadster, my version of Smoothwall I've been developing. The install initramfs contains a usable user environment for checking hardware, exploring disks, hacking the installer, and other stuff.

In fact, the standard initramfs *needs* a number of utilities in order to boot the system anyway. So put all the necessary booting/fixing progs in the initramfs, and put everything in /bin and /lib on the hard drive. Building with '--prefix=/' will handle most of it; the rest is in system-specific scripts and config files.

That said, I can still see a good reason to keep /usr separate. Keep the most commonly used utilities, programs and libs in / and put the rest in /usr: it may well make it easier to keep /bin, /sbin and /lib dirs cached (the dirs, not necessarily their contents). The less you have to hit the disk, the faster the system will be.

The case for the /usr merge

Posted Jan 27, 2012 4:47 UTC (Fri) by steffen780 (guest, #68142) [Link] (1 responses)

Booting without /usr has been broken for years? How curious, I'm doing that right now and I hardly have what I'd call stale software (kernel 3.2.1, gcc 4.6.2, kde 4.8.0, ...). So I can't boot? That's rather annoying indeed!

The case for the /usr merge

Posted Jan 27, 2012 5:34 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

In this context "broken" means "will fail to work under various circumstances in which you would expect it to work" rather than "will fail under all circumstances". The work required to make separate /usr work in all circumstances would involve moving a large part of /usr to /, which kind of defeats the point.

The fundamental problem with a separate /usr is that writing a tool that may be used in the booting of some estoric platform or setup would require you to limit yourself to the libraries available in /. Those vary across distributions, so which subset do you use? If you want to use a library that's in /usr, do you duplicate the functionality in your code or get every distribution to move it to /? What if that library has dependencies on a pile of other libraries that are currently in /usr as well? The / and /usr divide artificially split the platform in two, without any clear semantics as to which subset of functionality you can actually depend on. The world has got more complicated than it was when the worst case was /usr being on an NFS server connected by ethernet. Something has to change.

The case for the /usr merge

Posted Jan 27, 2012 2:22 UTC (Fri) by AndreE (guest, #60148) [Link] (4 responses)

Firstly, this is about merging /bin, /sbin and /lib* into /usr. No one is suggesting that /var and /etc. should be merged. Let's stick to the real argument here.

Secondly, are you seriously suggesting the that performance of these rescue tools are constrained by their startup time due to the slowness of rotational media? And if performance is actually of such great importance, then what you really should be doing is, as has been suggested by Lennart, building them into a ramdisk, which is still much much faster than an SSD. Either way, "performance of system rescue" is not a compelling argument for such separation.

The case for the /usr merge

Posted Jan 27, 2012 8:43 UTC (Fri) by kju (guest, #61936) [Link] (3 responses)

building them into a ramdisk, which is still much much faster than an SSD

You really believe this? It is likely much slower because the ramdisk needs to be completely loaded into RAM (and maybe unpacked) before it can be used. If you only use part of the content (selected binaries) you are loading lots of unnecessary stuff and in the end this is much slower than loading only the needed files directly from an SSD.

The case for the /usr merge

Posted Jan 27, 2012 9:54 UTC (Fri) by ebiederm (subscriber, #35028) [Link]

Last I benchmarked it I could load a full distro image compressed to about 800MiB in about 8 seconds over GigE. Almost enough time to notice I was waiting and then everything ran out of RAM.

Anything less than a full distro looks like too little data to even care about the performance on modern hardware.

The case for the /usr merge

Posted Jan 27, 2012 21:42 UTC (Fri) by AndreE (guest, #60148) [Link] (1 responses)

Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster

So what arbitrary measure should we use to benchmark our system rescue? The main point remains that "performance of loading binaries" is hardly a prime concern for system rescue situations.

The case for the /usr merge

Posted Jan 27, 2012 22:06 UTC (Fri) by dlang (guest, #313) [Link]

> Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster

as long as you have enough ram to both hold the ramdisk _and_ the working set for all your applications.

The case for the /usr merge

Posted Jan 27, 2012 10:29 UTC (Fri) by k3ninho (subscriber, #50375) [Link]

>absolutely essential OS tools could reside, if necessary, on a very small file system usable for all rescue scenarios

Am I stupid to think you can mount these small, stable, reliable filesytems as subdirectories within the /usr folder? I'd really like to join in the bikeshedding here, but the everything-is-a-file metaphor has a complementary everything-is-mounted-somewhere concept which leads me to think 'meh'.

K3n.