Linux Unix FHS：文件系统分层标准详解

需积分: 25 172 浏览量更新于2024-07-20 收藏 243KB PDF 举报

"Filesystem Hierarchy Standard (FHS) 是一个定义了Linux和类Unix操作系统中文件和目录放置的标准，旨在提高应用、系统管理工具、开发工具和脚本的互操作性，以及增强这些系统的文档一致性。" 正文: 在Linux和Unix系统中，Filesystem Hierarchy Standard（FHS）扮演着至关重要的角色。它定义了系统文件和目录应该如何组织，以确保跨不同发行版的一致性和兼容性。FHS由Linux标准基础（Linux Foundation's LSB Workgroup）制定并维护，其最新版本为3.0，发布于2015年。 FHS的核心目标是创建一个统一的文件系统结构，使得软件开发者、系统管理员和普通用户都能轻松地找到他们需要的文件和配置。这个标准包括了一系列的规定，明确了哪些类型的文件应该存放在哪个特定的目录下，以便于管理和维护。例如，FHS规定： 1. `/bin` 目录用于存放基本的用户命令，这些命令在系统启动时可以不依赖于其他目录中的文件。 2. `/sbin` 存放系统管理工具，通常只供root用户使用。 3. `/etc` 用于存储系统配置文件。 4. `/usr` 包含共享的可执行文件、库、文档等，分为多个子目录，如`/usr/bin`和`/usr/share`。 5. `/var` 存储运行时改变的数据，如日志文件、缓存和临时邮件。 6. `/home` 是用户个人目录的根，每个用户在此有自己的目录。 7. `/lib` 和 `/lib64` 存放系统运行所需的动态链接库。 8. `/opt` 用于安装附加的应用程序包。遵循FHS有助于保持系统的整洁，使升级和维护更为简单。同时，它也有助于确保软件能在各种符合FHS标准的Linux发行版上正常工作，降低了移植成本。开发人员在编写应用程序时，应考虑与FHS的兼容性，以便其产品能够无缝地融入不同的Linux环境。此外，FHS还强调了版权和商标保护，明确指出在复制或修改标准时必须保留版权和许可通知。这意味着任何基于FHS的工作都必须尊重原始作者的权益，并允许非营利性的复制和修改。 FHS是Linux和Unix生态系统中的基石，它促进了系统的标准化，提高了整体的可靠性和可维护性。理解和遵守FHS对于任何在这些平台上工作的IT专业人士来说都是至关重要的。

Chapter 2. The Filesystem

This standard assumes that the operating system underlying an FHS-compliant file system supports the

same basic security features found in most UNIX filesystems.

It is possible to define two independent distinctions among files: shareable vs. unshareable and variable

vs. static. In general, files that differ in either of these respects should be located in different directories.

This makes it easy to store files with different usage characteristics on different filesystems.

"Shareable" files are those that can be stored on one host and used on others. "Unshareable" files are those

that are not shareable. For example, the files in user home directories are shareable whereas device lock

files are not.

"Static" files include binaries, libraries, documentation files and other files that do not change without

system administrator intervention. "Variable" files are files that are not static.

Rationale

Shareable files can be stored on one host and used on several others. Typically, however, not all

files in the filesystem hierarchy are shareable and so each system has local storage containing at

least its unshareable files. It is convenient if all the files a system requires that are stored on a

foreign host can be made available by mounting one or a few directories from the foreign host.

Static and variable files should be segregated because static files, unlike variable files, can be

stored on read-only media and do not need to be backed up on the same schedule as variable files.

Historical UNIX-like filesystem hierarchies contained both static and variable files under both

/usr and /etc. In order to realize the advantages mentioned above, the /var hierarchy was

created and all variable files were transferred from /usr to /var. Consequently /usr can now

be mounted read-only (if it is a separate filesystem). Variable files have been transferred from /

etc to /var over a longer period as technology has permitted.

Here is an example of a FHS-compliant system. (Other FHS-compliant layouts are possible.)

shareable unshareable

static /usr /etc

/opt /boot

variable /var/mail /var/run

/var/spool/news /var/lock

Chapter 3. The Root Filesystem

3.1. Purpose

The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.

• To boot a system, enough software and data must be present on the root partition to mount other

filesystems. This includes utilities, configuration, boot loader information, and other essential start-

up data. /usr, /opt, and /var are designed such that they may be located on other partitions or

filesystems.

• To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to

diagnose and reconstruct a damaged system must be present on the root filesystem.

• To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must

be present on the root filesystem.

Rationale

The minimum requirements for the root filesystem should be as small as reasonably possible, but

no smaller. While many users may not want the extra complexity of a partitioned system, the

option to keep the root small should be preserved for several reasons:

• It is occasionally mounted from very small media.

• The root filesystem contains many system-specific configuration files. Possible examples

include a kernel that is specific to the system, a specific hostname, etc. This means that the root

filesystem isn't always shareable between networked systems. Keeping it small on servers in

networked systems minimizes the amount of lost space for areas of unshareable files. It also

allows workstations with smaller local hard drives.

• While you may have the root filesystem on a large partition, and may be able to fill it to your

heart's content, there will be people with smaller partitions. If you have more files installed,

you may find incompatibilities with other systems using root filesystems on smaller partitions.

If you are a developer then you may be turning your assumption into a problem for a large

number of users.

• Disk errors that corrupt data on the root filesystem are a greater problem than errors on any

other partition. A small root filesystem is less prone to corruption as the result of a system crash.

These considerations must be balanced against the need for a minimally useful operating

environment, for the sake of the boot process as well as in failure recovery situations.

Applications must never create or require special files or subdirectories in the root directory. Other

locations in the FHS hierarchy provide more than enough flexibility for any package.

Rationale

There are several reasons why creating a new subdirectory of the root filesystem is prohibited:

• It demands space on a root partition which the system administrator may want kept small and

simple for either performance or security reasons.

剩余49页未读，继续阅读

杨良全

粉丝: 4
资源: 9

Linux Unix FHS：文件系统分层标准详解

FilesystemHierarchyStandard-2.3.pdf

Filesystem HierarchyStandard-Version 2.2 final

Linux-Filesystem-Hierarchy.

Linux文件系统标准：Filesystem Hierarchy Standard详解

深入理解Linux文件系统：Filesystem Hierarchy Standard详解

Unix操作系统中的Filesystem Hierarchy Standard (FHS) 2.3

Linux Filesystem Hierarchy

linux_filesystem.rar_linux_linux 文件系统_linux_filesystem

springboot167基于springboot的医院后台管理系统的设计与实现.zip

XGigE IP GigE Vision Streaming Protocol VHDL源码 有基于AC701 FPGA板卡的完整的参考工程

最新资源

XGigE IP GigE Vision Streaming Protocol VHDL源码有基于AC701 FPGA板卡的完整的参考工程