File System

cramfs FileSystem Special compressed read-only?
ext2 FileSystem Default partition type used by Puppy
ext3 FileSystem More advanced version of ext2? Journalling??


http://sourceforge.net/projects/cramfs/∞
cramfs is a Linux filesystem designed to be simple, small, and to compress things well. It is used on a number of embedded systems and small devices.


http://www.nongnu.org/ext2-doc/∞

http://www.science.unitn.it/~fiorella/guidelinux/tlk/node95.html∞
The Second Extended File system (EXT2)

Figure: Physical Layout of the EXT2 File system

The Second Extended File system was devised (by Rémy Card) as an extensible and powerful file system for Linux. It is also the most successful file system so far in the Linux community and is the basis for all of the currently shipping Linux distributions.

The EXT2 file system, like a lot of the file systems, is built on the premise that the data held in files is kept in data blocks. These data blocks are all of the same length and, although that length can vary between different EXT2 file systems the block size of a particular EXT2 file system is set when it is created (using mke2fs ). Every file's size is rounded up to an integral number of blocks. If the block size is 1024 bytes, then a file of 1025 bytes will occupy two 1024 byte blocks. Unfortunately this means that on average you waste half a block per file. Usually in computing you trade off CPU usage for memory and disk space utilisation. In this case Linux, along with most operating systems, trades off a relatively inefficient disk usage in order to reduce the workload on the CPU. Not all of the blocks in the file system hold data, some must be used to contain the information that describes the structure of the file system. EXT2 defines the file system topology by describing each file in the system with an inode data structure. An inode describes which blocks the data within a file occupies as well as the access rights of the file, the file's modification times and the type of the file. Every file in the EXT2 file system is described by a single inode and each inode has a single unique number identifying it. The inodes for the file system are all kept together in inode tables. EXT2 directories are simply special files (themselves described by inodes) which contain pointers to the inodes of their directory entries.

Figure gif shows the layout of the EXT2 file system as occupying a series of blocks in a block structured device. So far as each file system is concerned, block devices are just a series of blocks which can be read and written. A file system does not need to concern itself with where on the physical media a block should be put, that is the job of the device's driver. Whenever a file system needs to read information or data from the block device containing it, it requests that its supporting device driver reads an integral number of blocks. The EXT2 file system divides the logical partition that it occupies into Block Groups. Each group duplicates information critical to the integrity of the file system as well as holding real files and directories as blocks of information and data. This duplication is neccessary should a disaster occur and the file system need recovering. The subsections describe in more detail the contents of each Block Group.


usr_cram.fs is actually a Squashfs file
http://squashfs.sourceforge.net/∞
http://tldp.org/HOWTO/SquashFS-HOWTO/∞

other How-Tos
http://tldp.org/HOWTO/∞


http://disktype.sourceforge.net/doc/ch03s05.html∞

3.5. Linux File Systems

Defining what actually is a "Linux" file system is difficult. Exchange between Unix flavors is vivid. Some of these file systems are borrowed from other flavors, others have been ported from Linux to other systems.

3.5.1. ext2 and ext3

The ext2 file system is "the" native file system for Linux nowadays. There was a predecessor called just extended file system, but support for it has long been eliminated from the Linux kernel. ext3 is a backwards-compatible extension that adds meta-data journalling.

ext2 is a fairly plain Unix file system, using an allocation bitmap and inodes. It has a superblock stored 1024 bytes into the device, independent of the block size used. All data is stored in little-endian byte order. The superblock contains some information not yet printed by disktype, including the originating operating system.

Information on ext2 can be found at http://www.nongnu.org/ext2-doc/∞. Other sources are the home page of the ext2 tools at http://e2fsprogs.sourceforge.net/∞, and the Linux kernel source code (see Chapter 4).

3.5.2. ReiserFS

ReiserFS was written with efficiency in mind. It handles large numbers of files per directory and large numbers of small files in general better than most traditional file systems. It makes extensive use of balanced trees and also provides meta-data journalling.

There are two major versions of the on-disk format, 3.5 and 3.6. ReiserFS on Linux 2.2 only supports the 3.5 format. Linux 2.4 ships with ReiserFS in the mainstream kernel, supports both formats, and is able to upgrade a file system on the fly to the new format. The two formats use two different magic strings in the superblock. A third magic string is used for non-standard journal sizes. (It seems this feature was added only recently and isn't actually supported by the mainstream Linux kernel yet.) In this case, the format is determined by an additional field in the superblock.

ReiserFS puts the superblock 64K into the device; some earlier versions put it 8K into the device. That allows complex boot loaders like GRUB to reside completely in the space before the actual file system. All data is stored in little-endian byte order.

Information on ReiserFS can be found at http://www.namesys.com/∞.

3.5.3. Minix

As the name suggests, the Minix format didn't originate on Linux, but on Minix, the PC Unix system after which Linux was modelled in its early days. The format is quite simple and compact, and was the preferred format for boot and install floppies for some time. Today, it has been superceded by ext2, and support for it will likely be removed in the next stable Linux kernel series.

Minix puts the superblock 1K into the device. There are two versions of the volume structures (most notably the inodes), and two maximum lengths for file names (14 or 30 chars). These parameters can be combined, yielding four actual formats, each with its own magic. disktype assumes that Minix is always little-endian, but I wasn't able to really confirm this yet.

3.5.4. romfs

romfs is a read-only file system intended for boot disks, initial ramdisks and the like. It does not use compression. When used with initrd, it can be stored in compressed form on the boot medium and is decompressed in whole while loading it into the ramdisk. The code for romfs is quite small, which results from data structures optimized for the Linux kernel.

Information on romfs can be found at http://romfs.sourceforge.net/∞.

3.5.5. cramfs

cramfs is a read-only file system intended for boot disks, initial ramdisks and the like. It improves on romfs by using compression within the file system. Decompression happens block by block as file data is accessed.

cramfs uses the native byte order and page size of each architecture, but doesn't store these parameters in the superblock. disktype determines the byte order from the magic number field, but the page size can only be guessed at. The superblock can start at the beginning of the device, or after one unused sector of 512 bytes.

Information on cramfs can be found at http://sourceforge.net/projects/cramfs/∞.

3.5.6. squashfs

squashfs is a read-only file system intended for boot disks, initial ramdisks and the like, currently under development. It tries to pack data really tight, without padding. A squashfs file system can occur with both byte orders, and the current driver can use both, independent of the running architecture. The byte order can be determined from the magic number.

Information on squashfs can be found at http://squashfs.sourceforge.net/∞.
A nice description is given here http://tldp.org/HOWTO/SquashFS-HOWTO/whatis.html∞

---

CategoryDocumentation