Files System Directories “Hierarchy” Part 2

Share it!!Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on Reddit0Share on StumbleUpon0

Hello guys,

here is the second part of Files system Directories

so here we go:

5. lib

The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin.

File Description
libc.so.* The dynamically-linked C library (optional)
ld* The execution time linker/loader (optional)

6. media

/media This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks.

Historically there have been a number of other different places used to mount removeable media such as /cdrom/mntor /mnt/cdrom. Placing the mount points for all removeable media directly in the root directory would potentially result in a large number of extra directories in /. Although the use of subdirectories in /mnt as a mount point has recently been common, it conflicts with a much older tradition of using /mnt directly as a temporary mount point.

Directory Description
floppy Floppy drive (optional)
cdrom CD-ROM drive (optional)
cdrecorder CD writer (optional)
zip Zip drive (optional)

On systems where more than one device exists for mounting a certain type of media, mount directories can be created by appending a digit to the name of those available above starting with ‘0’, but the unqualified name must also exist.

7. mnt
Mount point for a temporarily mounted filesystem

/mnt  This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run.

This directory must not be used by installation programs: a suitable temporary directory not in use by the system must be used instead.

8. opt

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and<provider> is the provider’s LANANA registered name.

9. root

/root     Home directory for the root user

The root account’s home directory may be determined by developer or local preference, but this is the recommended default location.

10. sbin

/sbin    System binaries

Utilities used for system administration (and other root-only commands) are stored in /sbin/usr/sbin, and /usr/local/sbin/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin.

11. srv

Data for services provided by this system

/srv contains site-specific data which is served by this system.

This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users’ home directory.

The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftprsyncwww, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www/srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.

Distributions must take care not to remove locally placed files in these directories without administrator permission.

12. tmp

The /tmp directory must be made available for programs that require temporary files.

Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section.

Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.

13. usr

/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

Large software packages must not use a direct subdirectory under the /usr hierarchy.

14. var

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

Some portions of /var are not shareable between different systems. For instance, /var/log/var/lock, and /var/run. Other portions may be shared, notably /var/mail/var/cache/man,/var/cache/fonts, and /var/spool/news.

/var is specified here in order to make it possible to mount /usr read-only. Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var.

If /var cannot be made a separate partition, it is often preferable to move /var out of the root partition and into the /usrpartition. (This is sometimes done to reduce the size of the root partition or when space runs low in the root partition.) However, /var must not be linked to /usr because this makes separation of /usr and /var more difficult and is likely to create a naming conflict. Instead, link /var to /usr/var.

Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list.

——————-

that’s it for now

and i will include graphic chart later

Share it!!Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on Reddit0Share on StumbleUpon0
6 Comments

Add a Comment

Your email address will not be published. Required fields are marked *