linux file system structure

Linux File System Structure The Linux system contains thousand of files located within many directories. All directories are organized in a tree-structure like manner.
The 'trunk' of the tree is the root directory. The root directory is simply identified as a "/". All other directories 'branch' off from the trunk. The following lists the most common directories and their intended contents.
/ - root directory

/home - where directories are contained for each user, example: /usr - pronounced 'user' and contains Linux commands and utilities

/bin - binary executable programs

/lib - program libraries, similar to Windows 'dll' files

/sbin - more executable programs and Linux utilities for administrative purposes

/doc - documentation

/src - source code to programs

/tmp - temporary work files /etc - configuration files

/rc.d - scripts used during boot and shutdown process

/sysconfig - default configuration files

/sysconfig/network-scripts - network scripts

/sysconfig

/daemons - special programs that run in background, such as print spooling

/bin - binary executable programs that all users need

/dev - device files that control drives, terminals and any equipment attached to the server

/var - user specific files

/log - log files containing system usage and errors

/spool - where spooled files are stored during print spooling process

/mail - where Email files are stored until retrieved by client Email program

/proc - system files

/root - root's home directory

/opt - other options

/sbin - more executable programs and utilities

database vs file base system

. In general, file-based servers perform better when update operations are very large or instances are relatively small, while databases are best when small updates are frequently performed against large instances. 2. Files tend to be much faster to read than databases. The startup time depends primarily on the time it takes to read the server�s instances, so using a database backend may more than double startup times. 3. When creating, copying, or modifying a repository instance the entire instance needs to be written, so file-based instances tend to be faster. Deleting instances is especially faster for file-based instances because it involves a single operating system operation, file delete, as opposed to the query and deletion of all appropriate rows in the database. 4. When using the repository server�s fault tolerant feature, multiple servers are run all serving the same data. Common data can be shared either by using a common persistent store such as a shared database or network mounted files, or by replicating the persistent store. For databases, it is very easy for all servers to share a common database. For files, using a network mounted file introduces a single point of failure. Replicating file instances so each server has a local instance on its system provides for a complete fault tolerant solution with each system able to run independently. However, replicating files introduces an additional process that can break down leading to inconsistencies in the data being served. 5. Files have no cost other than the IT overhead of supporting a backup process. Databases on the other hand can be expensive if you do not have a site-license with one of the supported database vendors. In summary, the choice of file versus database will depend on your particular situation. Performance is an important factor, but it is not the only one, because so much of performance is not related to the backend storage choice. Reliability and cost should also be considered when selecting the appropriate solution.