Hi, On 02/15/2012 12:54 AM, Jonathan Vasquez wrote:
I didn't want to introduce ideas that would delay FHS 3.0, so this is mean't for FHS 3.1+.Dear FHS Contributors, We have been using the current and wonderful Filesystem Hierarchy Standard for quite some time now, and it has been great. However, the times have changed. We have amazing new technology, and we need to relook at how the structure of the Linux filesystem should be designed. Our current filesystem has multiple directories that are no longer necessary to have, need to be merged, and or need to be relocated. The current filesystem layout looks like this: Current Base Layout /bin - Essential Binaries /sbin - Essential System Binaries /boot - Boot Files /dev - Device Files /etc - System Configuration Files /lib - Essential System Libraries /lib<arch> - Essential System Libraries for Target Architecture /media – Mount Point for Removable Devices /mnt - Mount Point for mounting a filesystem temporarily /opt - Optional (Add-On) Software Packages /srv - Service Data /tmp - Temporary Files /usr - User Applications (Secondary Hierarchy) /var - Variable Files /home - User Directories (Documents, Videos, Music, ..) /root - root's Home Directory /proc - Kernel Process Information /sys - Kernel Device Information This is a total of 18 directories (Including /proc and /sys). The problem here lies in a few things: Segregation of all binaries and libraries from other binaries and libraries in the system Redundant folders for mount points Separate home directory for root Temporary file directory should belong with other changing data (/var) Kernel Information folders are right at the root level. Multiple library directories are at the root level. Optional Software Packages directory is at the root level Multiple but Equal Hierarchy's (/ and /usr and /usr/local) In order to clean this up and make a smaller, and consistent filesystem layout, we need to restructure. The following directory structure is what I propose to resolve our above issues: Proposed Base Layout /boot - Boot Files /srv - Service Data /dev - Device Files /etc - System Configuration Files /mnt - Mount Points for all devices → /floppy ← Example → /cdrom ← Example → /usb ← Example → /sda1 ← Example /var - Variable Files → /tmp - Temporary Files /home - Home Directories → /root - root's Home /krn - Kernel Directories → /proc - Kernel Process Information → /sys - Kernel Device Information /usr - User Applications → /bin - Binaries → /sbin - System Binaries → /opt - Optional (Add-On) Software Packages → /local - Local Applications Directories → /libs - Libraries and Kernel Modules → → 32 ← Example of Libraries for 32 bit applications → → 64 ← Example of Libraries for 64 bit applications As you can see, this would reduce the base directory by 50%. Meanwhile it will bring back the directories to their logical locations. This has the following benefits: /media and /mnt are now merged. All devices being mounted to the machine will be contained in separate directories within a single directory: /mnt Temporary Files change all the time, and thus should be located in /var/tmp The root's home directory is now actually within the /home directory There is a new directory called /krn (kernel) created for containing kernel information All the applications in the system can now be consistently and logically be found in one place: /usr. Binaries which do not require administrative privileges would tend to go in /usr/bin, while binaries that require administrative privileges would go in /usr/sbin. /opt(ional) packages are now also found in the /usr directory since they are also programs, but probably programs that require all their files and layout to be relative from each other. There is a new directory inside /usr called /libs. This directory is in charge of holding the libraries and kernel modules for the system. This takes it away from the base of the system, and also puts it into a logical location. /usr maintains it's “read-only-mount elsewhere/reuse” attributes since the /var files are still separate from /usr. /usr/local is kept since it lets us cleanly install applications that are outside of our distribution's package management system. This has the ability to keep a clean system, and separate user installed binaries from binaries tracked by the system. I would say that this directory could normally be used for testing package builds on the system without having to have a separate chroot environment. (The chroot environment is recommended, but this is just food for the mind). Booting the system with this new directory organization should not be a problem at all. With the initramfs, we could easily continue to create initrds that hold the essential binaries and libraries to boot the particular system. Whether it is LVM, RAID, Encrypted RAID, or any other combination. Just mount the root and /usr partitions, and you are good to go. You can also slowly start to move away from MBR and start embracing GPT to have the added advantage of additional partitions, checksums, and GPT header redundancy (front/back table backups). This let's you organize and separate the partitions in the / partition easily. You could even put all nine directories in a separate partition using GPT if you wanted to, but I do not recommend it. I hope my above suggestions will have an impact in the future of Linux/and UNIX filesystem designs.
Interesting and you certainly provide appropriate arguments for making changes. However, just addressing this here on the FHS list will not be sufficient to gather momentum to propagate changes into distributions.
The merge of binaries from /bin, /sbin to the /usr tree, while progressing in various distributions, is not necessarily welcomed with open arms. Your proposed changes are much more far reaching.
Consider that to this point the FHS documents common practice, and is not a leading standard. Whether or not we can turn the FHS into a leading standard can be debated. In any event it is not the case that we develop FHS and distributions follow.
You might also take your proposal to freedesktop.org to solicit opinions from a broader audience. I am not certain we have a critical mass of subscribers on this list to build momentum. See http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge as an example.
Also moving things related to the kernel would have to be discussed on LKML. My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead [email protected] [email protected] 781-464-8147 _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
