ADIOS Project

-- Live Linux ADIOS CD home

ADIOS Filesystem Structure

There are problems with the Linux filesystem layout when you want to create live CDs.  The original design of Unix was to place files of the same type and function in the same directory.  For example all binary files into the directory /bin, all users into the directory /users and all configuration files into the directory /etc.  Although this approach is followed up to a point there are many examples of files such as scripts that reside in the configuration directory and executable binaries that reside in the libraries directory /lib.  By far the biggest problem is that many files should be placed within a read only filesystem as they do not change except for upgrades to the operating system.  Alternatively files that need to changes are often found within the supposedly read-only files tree /usr.  The solution is to create the directory trees and place files into the correct containers and to provide backward compatibilty link these files from their current locations.

Linux / (root) filesystem structure is all read-write.  First lets examine the standard / (root) filesystem layout, which contains the following directories.

Many of the sub-directories contain read-only files, while others are mainly read-write files.  In addition there is not need to backup the read-only files more than a few times as they don't change until the next patch or upgrade.  However files that change the so called read-write files are scattered throught the directory tree.  The simplest solution is to relocate these files, for example /etc, /root, /home and /tmp could be placed on three read-write partitions or moved to /var.  Links from the root driectory into /var for each of /etc, /root, /home and /tmp will provide the backward compatability needed to be able to upgrade packages.  The problem is everywhere, directories such as /usr/local and /usr/src could be used to implement changes while /var/lib/rpm will not change until the next upgrade osf a software package. 

There are several list of files that can be categoried into classes.

• READ-ONLY - files that do not change until package is upgraded.
• READ-WRITE - files that can change at any time such as those withinthe directories /var, /tmp, /etc, /root, and /home.
• READ-UPDATE - files that change on startup or shut-down. these files are useful for running Linux on Windows fileystems.  Effectively allowing the operating system to read the previous state of configuration and users files from disk and write these to RAM, then at shutdown or at regular intervaks write changes to disc file.  ADIOS has tried to implement this concept by using USB storage devices.
• WRITE-APPEND - files that grow in size but attributes such as date change, these files are required when you want to validate an audit or used by forensic tools.  An example of the simplest implementation is to use CDRs in append mode.

In comparison, the ADIOS file structure has several sections, the / RAM disc (read-write), the /adios tree (read-only, contains /bin, /sbin and /lib), the /usr tree (read-onl;y), the /opt tree (contains mount points for openoffice, uml and www) and the /var tree (read-write), which is either in a RAM drive or placed on disc.

Another solution is to use a copy-on-write technology so that the filesystem can remain relatively unchanged.  The ADIOS distribution allows you to select "unionfs" on startup, then all files that are read-only use copy-on-write technlogy allowing you to add, delete and modify files.
 

Problems with Multiple Languages on Linux

A major problem for Linux and other operating systems is how to handle multiple languages.  Committees and organisations have developed standards which have proposed file structure layouts.    The implementation of language support unfortunately is far from perfect.  The original design of Unix was to place files of the same type and function in the same directory.  The creation of a directory to contain all langauge specific files for example error messages, pull down menus or manuals would seem a practical solution.

The current approach used within Linux is a good example of what happens when industry has created a solution.  Many application developers have placed language support files within a share or library associated with the application or even within the documentation tree /usr/share/doc.  The multiple language support provided within Linux is currently a set of directories where developers can place language specific files.  The /usr/lib/locale directory is used for locale environments such as character classification and case conversion, collation order, date and time formats, non-monetary numeric formats, monetary formats, formats of informative, diagnostic messages and iteractive responses.  The /usr/share/locale directory tree houses more language specific information.  The Linux developes placed the language manual entries in separate folders within /usr/share/man.  While software developers have created their own locations, for example the KDE graphic language specific menus are placed in /usr/share/doc/HTML.  This makes perfect sense from the view of an application developer but does not lead to a nice structured approach to maintain the Linux filesystem.  The original goal was to separate file types such as binary files, libraries, manuals, configuration files and place these into separate directory trees.  It makes sense to do the same thing with language codes.  

The following table displays the current locations of Language Codes (LCs) and two alternative proposals for the location of language files.  Both proposals place all of the language files within a single directory tree.  The first proposal reflects the current locations using a simple mapping.  The second soluion is to group all language codes first, which has the advantage of placing all of a single language within its own sub-directory tree.  Unfortunately this would mean rebuilding all applications for a particular Linux distribution.  The question is how to handle multiple languages not locations.

As a first attempt to address this multiple language support problem, the ADIOS file tree is using a separate directory /opt/lang similar to proposal 1 above.  This tree can then be replaced with subsets of langauges so that the total filesize can still fit on a single CD image.

ADIOS file structures

The initial / (root) RAM disc (READ-WRITE) contains the following directory trees and soft links.

The /adios tree (READ-ONLY) contains /bin and /sbin binaries and /lib libraries.

The /usr tree (READ-ONLY) contains all of the /usr binaries, libraries, and share files

The /var tree (READ-WRITE) contains the configuration files, log files, user files and temporary files.

Written by Neville Richter, n.richter@cqu.edu.au Copyright GNU Public Licence 2006.