LWN: Comments on "Filesystem hierarchy standard 3.0 process begins"

Filesystem hierarchy standard 3.0 process begins

wookey — Tue, 17 May 2011 12:15:17 +0000

I don't think multiarch has prompted this resurrection, but it is relevant. The timing is perhaps rather unfortunate in that regard. Multiarch is not a new idea (initially proposed in Debian in 2005 IIRC), but it has only just made it into real distributions (Ubuntu Natty release a week or so ago). That makes it rather too young to be adopted as something to mandate in the FHS. On the other hand if it's going to be a few years before we get another it'd be nice to have it as an option, or mentioned, or something.

We'll be bringing this subject up to see what people thing about it, but I imagine that at the moment most people's reaction to the multiarch stuff is that it is weird Debian/Ubuntu craziness, best ignored. Now in fact it's a powerful and useful concept which I hope will have a long and friutful life, but clearly it's too early to make big claims about how it will create cross-architecture nirvana in filesystem-trees.

Filesystem hierarchy standard 3.0 process begins

The_Barbarian — Tue, 17 May 2011 06:15:08 +0000

Yes please

Filesystem hierarchy standard - questions about /boot

tack — Fri, 13 May 2011 18:39:22 +0000

That isn't necessary anymore with GRUB 2.

Filesystem hierarchy standard 3.0 process begins

elanthis — Thu, 12 May 2011 03:45:45 +0000

I myself may have been an idjit and mistyped that. :)

Filesystem hierarchy standard 3.0 process begins

dtlin — Tue, 10 May 2011 18:10:18 +0000

$XDG_CONFIG_HOME?

Filesystem hierarchy standard 3.0 process begins

hnaz — Tue, 10 May 2011 07:39:20 +0000

Fantastic! Time to standardize the dotfiles, so I can maintain ~/.etc in git without interfering temp files, logs, and caches :)

Filesystem hierarchy standard 3.0 process begins

Hausvib6 — Sat, 07 May 2011 10:37:39 +0000

Agree, like HTML5. Browsers implements new features all the time, ahead of each other, so does GNU/Linux distros adding new/renaming/moving directories in the filesystem.

Filesystem hierarchy standard - questions about /boot

Wol — Fri, 06 May 2011 22:27:13 +0000

And on one of my systems I have doze on hda, linux on hdb, grub as my bootloader, and I couldn't get an hdb /boot to work ...

Mind you, I get the impression from the OP that's okay because / and /boot are on different hard drives.

Cheers,
Wol

Obviously it SHOULD be there :-).

david.a.wheeler — Fri, 06 May 2011 21:26:07 +0000

Sounds great! I believe all the officially-named directories are already UTF-8 compliant (as they only use the ASCII subset), so in THAT sense they are there already. If you can't *mandate*, the FHS could at least *recommend* that all filenames be UTF-8 encoded. That's where all the desktops are slowly going anyway; there's no way to include encoding information about filenames in the filesystems, and the environment variables have the wrong scope. Even just a *recommendation* might help push everyone else that way. Then at least we could *display* filenames :-).

Filesystem hierarchy standard 3.0 process begins

zooko — Fri, 06 May 2011 20:22:30 +0000

Haha! That's funny.

Filesystem hierarchy standard 3.0 process begins

cry_regarder — Fri, 06 May 2011 20:15:41 +0000

Where things go:

-- Things that aren't named in UTF-8 go __no_where__

What directories exist:

-- Directories that aren't named in UTF-8 do __not_exist__

Filesystem hierarchy standard 3.0 process begins

rfunk — Fri, 06 May 2011 19:37:13 +0000

I'm pretty sure all your questions are answered in the text of the FHS.

Filesystem hierarchy standard 3.0 process begins

rfunk — Fri, 06 May 2011 19:36:35 +0000

That's outside the scope of the FHS, which merely defines where things go and what directories exist.

Filesystem hierarchy standard 3.0 process begins

zooko — Fri, 06 May 2011 19:24:18 +0000

Would it make any sense to try to get FHS people to look at David Wheeler's "fix POSIX file names by outlawing insane stuff" proposal?

http://www.dwheeler.com/essays/fixing-unix-linux-filename...

As a working data/filesystem hacker (http://tahoe-lafs.org ), the things that bother me are all things that Wheeler brought up, starting with "you can't know what encoding these bytes were originally supposed to be in". If we could get someone with a semblance of authority to publicly announce that using an encoding other than utf-8 on your linux file system is non-standard and won't be universally supported then that would be a good start.

Filesystem hierarchy standard 3.0 process begins

tchernobog — Fri, 06 May 2011 14:56:42 +0000

I never really understood the need for /srv. On most machines I had, it was there but empty. Services use something under /var/lib, mostly. Do we really need to have a gazillion directories under root?

Also, I have seen the /mnt vs. /media thing baffle out more than one user. If I have an external USB HDD always attached to my machine it goes to /media, okay. But what is the rationale of mounting other things such as network shares in /mnt? It's almost always empty, nowadays. When I mount something for a short while, I just do a "mkdir temp; mount -t auto /dev/something temp" in my home or in /tmp if it should be accessible for other users.

PS: as far as I know, /opt has been used in the past years mostly either in place of /usr/local, or for installing proprietary apps like Google Earth and Oracle. Maybe they should make that clearer.

Filesystem hierarchy standard 3.0 process begins

intgr — Fri, 06 May 2011 12:15:46 +0000

Surely this controversy is not critical enough to warrant the attention of FSB, Russia's Federal Security Service? :)

FHS + LSB = FSB?

Filesystem hierarchy standard - questions about /boot

anselm — Fri, 06 May 2011 09:05:38 +0000

Nothing in the FHS says that /boot must be on its own partition. Under some circumstances this is unavoidable (e.g., with some LVM and/or encryption setups), and historically it used to be necessary on various machines due to BIOS limitations. However there is nothing wrong in principle with having /boot on the root file system along with /etc, /bin and so on, just as there is nothing wrong with having it on its own partition. The FHS makes no stipulation either way.

Filesystem hierarchy standard - questions about /boot

niner — Fri, 06 May 2011 08:02:52 +0000

One still needs /boot on it's own partition if one is using LVM for root or a file system not supported by one's bootloader.

Filesystem hierarchy standard - questions about /boot

petegn — Fri, 06 May 2011 07:53:19 +0000

Why do we have to mess with it at all the last thing wanted is yet more need for extra partitions boot works quite well as an dir on / there is no need for an separate partition < i have not too much knowledge of the FHS but certain things just strike me as a retrograde step we used to have /boot as an partition years ago i do not want to see it return

Filesystem hierarchy standard 3.0 process begins

Kamilion — Fri, 06 May 2011 04:33:06 +0000

Also, the moving of /selinux to /sys/fs/selinux noted here:

http://lists.freedesktop.org/archives/systemd-devel/2011-...

and backed by Greg KH

Filesystem hierarchy standard - questions about /boot

dlang — Fri, 06 May 2011 03:38:38 +0000

>> Just make sure that you understand _why_ you are violating the standard, (and if you are doing this for anything beyond your personal systems, document what you are doing strange and why), then go on with life.

>Funny thing was, I didn't think I was violating any such standard with the separate /boot partition. I openly admit to being ignorant of the FHS, or even the mere existence of such a standard (well, not totallyI might've read about the FHS some time ago). Which sort of explains why I asked here.

well, if nothing else you were violating the 'standard' of your distro. If you are ever going to have anyone else involved with maintaining the system, you can get away with not documenting the distro, but you should document what you change from the default.

Filesystem hierarchy standard - questions about /boot

pr1268 — Fri, 06 May 2011 02:16:24 +0000

> Just make sure that you understand _why_ you are violating the standard, (and if you are doing this for anything beyond your personal systems, document what you are doing strange and why), then go on with life.

Funny thing was, I didn't think I was violating any such standard with the separate /boot partition. I openly admit to being ignorant of the FHS, or even the mere existence of such a standard (well, not totally—I might've read about the FHS some time ago). Which sort of explains why I asked here.

> I think that there is a lot of good thinking in your decision. I'm not sure I would go to that much effort, but I won't say that you are wrong to do so.

Thank you (and anselm) for your words of encouragement.

> (I am also someone who ops to use lilo instead of grub)

I use LILO because I run Slackware on my computers (and Slackware's philosophy is also "if it ain't broke, then no need to fix it" [and LILO still works great despite its antiquity]).

> One of the big pains to deal with in running production systems is when the distro and the upstream disagree on where a critical package lives (or where it's config files, or loadable modules, etc live). This makes it unnecessarily hard to upgrade to a custom built version of the package when your installation needs something different from the distro default.

Don't I know it! (My experience at trying to install 3rd-party ProFTP and PAM/MySQL RPMs onto a CentOS 5.1 box several years ago turned into a nightmare [CentOS's own VSFTP implementation was out of the question as it didn't support the authentication scheme], but I digress...).

Back to the FHS-2.3 document, I would like to express gratitude at its enlightening me on the difference between /mnt and /media, and also for explaining the rationale for separating /bin and /lib from their /usr counterparts.

Finally, to add to the discussion/debate above, I do think that (a) the seven years have elapsed because (again) it wasn't broken and no need to fix it, and (b) creating a /run directory obviates the need for a standards update. Obviously. </sarcasm>

Filesystem hierarchy standard - questions about /boot

dlang — Thu, 05 May 2011 23:39:59 +0000

your system is non-complient (and _any_ system is not recommended, by _someone_ ;-)

but that doesn't really matter

the FHS is a standard for application packagers (either distros or independent) to give them guidelines as to where they should install the various components of their application by default.

not only is the nice thing about standards is that there are so many to choose from, but no matter what the standard is, there is always going to be some situation, somewhere, some time, where the right thing to do is going to be to violate the standard.

Just make sure that you understand _why_ you are violating the standard, (and if you are doing this for anything beyond your personal systems, document what you are doing strange and why), then go on with life.

I think that there is a lot of good thinking in your decision. I'm not sure I would go to that much effort, but I won't say that you are wrong to do so. (I am also someone who ops to use lilo instead of grub)

now if a distro violates the FHS, or if someone makes their 'make install' do things that violate the FHS, then you should complain, and probably do so fairly loudly. One of the things that makes the *nix ecosystem work is that applications built and configured for one distro/OS can work on others with relatively few problems. one of the keys to making this work is standardising where things are installed.

One of the big pains to deal with in running production systems is when the distro and the upstream disagree on where a critical package lives (or where it's config files, or loadable modules, etc live). This makes it unnecessarily hard to upgrade to a custom built version of the package when your installation needs something different from the distro default.

Filesystem hierarchy standard - questions about /boot

anselm — Thu, 05 May 2011 23:23:06 +0000

Frankly I don't see what your problem is here. The rules in the FHS apply to distributors and application developers. As a system administrator you are perfectly free to arrange your own system as you see fit the FHS tells you which bits of the file system you should avoid because the distribution is allowed to futz around with them, but other than that, whatever floats your boat is fine.

In particular I don't think there's anything gravely wrong with not having the content of the /boot directory accessible during normal system operation. Also there ought to be no problems with GRUB provided that GRUB can get at the partition in question when the system is booted.

Filesystem hierarchy standard - questions about /boot

pr1268 — Thu, 05 May 2011 23:03:28 +0000

So, if I'm to understand the (existing) FHS-2.3 document, then my below configuration is non-compliant (or not recommended):

/boot is a separate partition and filesystem on the same physical disk as the / partition/FS;
/boot is not mounted by default; i.e., the "noauto" option is located in my /etc/fstab file;
The bootable kernels reside in the /boot partition, and the boot manager points to their physical location on the disk (I use LILO), so booting isn't affected by the separate partition;
Since the kernel is loaded into memory at boot time, then access to the files in the /boot partition isn't needed during normal operation¹, unless I'm installing a new kernel and/or adjusting LILO configuration settings (during which I have the partition mounted);
A /boot directory still exists even when the /boot partition isn't mounted (although it is empty);
Should the physical disk drive give up the ghost, then the separate boot partition wouldn't help me or hurt me (but I'd have other issues to deal with, obviously);
My rationale for this is so that normal use of the computer won't cause any "accidents" where kernels and System.maps might get dorked with (Malware comes to mind, but my occasional carelessness is probably a bigger threat to my computer than any malware! ;-) )

Is this not recommended? This technique was suggested to me by a friend at a LUG meeting a few years ago, and I've done it since without any trouble whatsoever (so far). Should I assume a separate /boot partition with kernel images will not work with GRUB? Discussion is appreciated.

I apologize if this is not the proper venue to discuss this, but that FHS-2.3 document linked on this page seemed to contradict what I'm doing, so I think it's pertinent. Thanks!

¹ I don't use an initrd, and /lib/modules (containing all the run-time loadable kernel modules) is part of the / filesystem.

Filesystem hierarchy standard 3.0 process begins

alvieboy — Thu, 05 May 2011 19:45:44 +0000

This boils down to basically:

"If it ain't broke, don't fix it".

So far it was suited everyone needs, but sometimes we need to take another step towards what's considered de-facto standards or recent best practices, or just, well... moving on.

Nothing is eternal. Not even standards.

Filesystem hierarchy standard 3.0 process begins

clugstj — Thu, 05 May 2011 19:24:17 +0000

This is a standards document, not some "we can fix it later" code. If we've got to put up with what's in it for the next 7 years (or explain over and over why we are ignoring it), then it'd better not be a rush job.

Filesystem hierarchy standard 3.0 process begins

elanthis — Thu, 05 May 2011 18:26:46 +0000

Why should tweaks to a simple document take more than a few
Months? He'll, why should it take more than a few weeks? You've spent too long in waterfall-managed corporate bereucracies, friend.

Filesystem hierarchy standard 3.0 process begins

elanthis — Thu, 05 May 2011 18:23:40 +0000

The big stink over /run raised by whiny idjits is likely the only reason anyone is bothering with a new FSB, so yeah, expect it to be there.

Filesystem hierarchy standard 3.0 process begins

rfunk — Thu, 05 May 2011 18:16:10 +0000

I don't think there's any drastic change happening, just updates to account for modern scenarios. Nor do I think there are many people clamoring for a DJBIX view of the filesystem.

Filesystem hierarchy standard 3.0 process begins

clugstj — Thu, 05 May 2011 18:08:59 +0000

There is no release for 7 years and suddenly they need to have the next release out in 3 months? What's the hurry?

Filesystem hierarchy standard 3.0 process begins

euske — Thu, 05 May 2011 16:58:03 +0000

I think the points raised by D. J. Bernstein years ago are still valid. Hopefully they take some of his advice if they're drastically changing things. cf. http://cr.yp.to/slashpackage.html

Filesystem hierarchy standard 3.0 process begins

rfunk — Thu, 05 May 2011 16:18:46 +0000

Follow that Bugzilla link and do a blank search there, selecting FHS as the product. That'll give you a page of issues people have logged so far. (Some are years old, but others are more recent.)

Filesystem hierarchy standard 3.0 process begins

Jonno — Thu, 05 May 2011 16:17:57 +0000

From what I've read, the two issues promoting FHS3 are /run and /lib/<architecture triplet> (aka debian multiarch), though more changes may still be added to it.

Filesystem hierarchy standard 3.0 process begins

eMBee — Thu, 05 May 2011 16:09:26 +0000

i expect it to be little tweaks, add in all the current practices that have cropped up in recent years (like /run). the whole process has been pretty much dead for some time, and i am happy to see some attempts at revival to take shape.

greetings, eMBee.

Filesystem hierarchy standard 3.0 process begins

ssam — Thu, 05 May 2011 15:56:14 +0000

is there somewhere that gives the broad aims of the new version? what are the big complaints with the current one.

Are they going for something radical (like MacOSX or gobolinux). Or is it little tweaks?

Filesystem hierarchy standard 3.0 process begins

Hausvib6 — Thu, 05 May 2011 15:53:08 +0000

/run should be added to the new FHS.