eComStation: vai alla Homepage This website in english Versione Italiano Diese Webseiten auf Deutsch

Login cliente
Nome utente:


Registrati come nuovo utente

eCS Newscast
Grazie a questa mailinglist, potrai conoscere notizie e voci su eCS appena usciranno.

Indirizzo email:

© 2003-2007 Serenity Systems, Inc. 2003-2013 Mensys BV, 2014-2015 BV. All rights reserved.

Questo sito gira su eComStation

Journaling  File System
Journaling File System Manda questa pagina a un amico Manda questa pagina per posta
JFS Features
JFS Volume Structure
File System Comparison
JFS Implementation
JFS Utilities

JFS Features

Until now, the best file system available for eComStation was the High Performance File System (HPFS). When it was first developed, it was truly innovative, and it is still far superior to the File Allocation System (FAT) and any of its versions. However HPFS has failed to keep up with the times, and is becoming obsolete. In particular, HPFS has the following significant limitations:

HPFS is a 16-bit system;

HPFS uses a maximum 2MB cache;

HPFS has a 2GB maximum file size.

In an attempt to rennovate HPFS, a 32-bit version of HPFS called HPFS386 for its server products. However this product was never widely distributed. We can only speculate on the reasons, but it may be that HPFS386 failed to overcome some of the other more basic restrictions inherent in HPFS. Clearly eCS needed, or at least wanted, something completely new. For this they developed an eCS version of the AIX Journaled File System. Let us now look at some of the new features JFS brings to eCS that has users so excited.

A truly 32-bit system;

Maximum volume size 2 terabytes (=2,048 gigabytes!)

Maximum file size 2 terabytes (=2,048 gigabytes!)

This is especially important for large database and server users.

In conjunction with LVM, JFS allows dynamic volume expansion. In other words, volumes can be increased in size "on the fly"!

Maximum cache size is the amount of available physical memory.

Uses database journaling techniques to record changes sequentially in a special log, so that in case of system failure, data can be restored much faster than was possible under previous file systems.

The following paragraph was taken from Quick Beginnings1 and does a good job of demonstrating the amount of effort put into enhancing JFS as they created the eCS implementation:

The Journaled File System (JFS) is a file system that uses database journaling techniques, such as recording file changes sequentially, to maintain file system integrity. JFS provides a high-performance, 32-bit file system implementation for the eCS environment. JFS is tailored primarily for the high throughput and reliability requirements of servers from single processor systems to advanced multiprocessor and clustered systems where performance and reliability are desired. JFS uses the proven technology of the existing AIX JFS implementation, and it is enhanced to provide support for extended attributes, unicode names, and case-insensitive searches. Also a number of significant features are added to JFS to make it more competitive and scalable, resulting in fundamental changes to the file system layout. These features include extent-based allocation, sorted directories, and dynamic space allocation for file system objects.

To complete our description of JFS features, I have included below a diagram of the JFS disk layout. 2 Refer to this redbook for complete details on each component of the diagram. In fact, for anyone who intends to spend a substantial amount of time using the technical aspects of eCS this book should be considered a must.

JFS volume structure

JFS is organized like a traditional Unix-ish file system, it presents a logical view of files and directories linked together to form a tree-like structure. This is the concept that spread from the Unix world pretty much everywhere else and that we all know. JFS has some obvious advantages when compared to HPFS and HPFS386 (some shortcomings too). There are two significant advantages:

  1. capacity - JFS allows much larger file and volume sizes than HPFS. Basically JFS is a 64-bit file system while HPFS structures are at most 32 bits large.
  2. recovery - thanks to the journaling techniques employed by JFS (described in more detail later), CHKDSK times for JFS are significantly faster than for equivalent HPFS volumes. Roughly speaking, where HPFS checkdisk after a crash takes minutes, JFS takes seconds.

JFS is created on top of a logical volume. To maintain information about files and directories, it uses the following important internal structures:

  • the superblock
  • the i-nodes
  • the data blocks
  • the allocation groups

The superblock lies at the heart of JFS (and many other file systems). It contains essential information such as size of file system, number of blocks it contains or state of the file system (clean, dirty etc.).

The entire file system space is divided into logical blocks that contain file or directory data. For JFS, the logical blocks are always 4096 bytes (4K) in size, but can be optionally subdivided into smaller fragments (512, 1024 or 2048 bytes).

An i-node is a logical entity that contains information about a file or directory. There is a 1:1 relationship between i-nodes and files/directories. An i-node contains file type, access permissions, user/group ID (UID/GID - unused on eCS), access times and points to actual logical blocks where file contents are stored. The maximum file size allowed in JFS is 2TB (HPFS and FAT allow 2GB max). It should be noted that the number of i-nodes is fixed. It is determined at file system creation (FORMAT) time and depends on fragment size (which is user selectable). In theory users could run out of i-nodes, meaning that they would be unable to create more files even if there was enough free space. In practice this is extremely rare.

Fragments were already briefly mentioned in the discussion of logical blocks. The JFS logical block size is fixed at 4K. This is a reasonable default but it means that the file system cannot allocate less than 4K for file storage. If a file system stores large amounts of small files (< 2K), the disk space waste becomes significant. We've all got to know and hate this problem from FAT (cluster size of 32K leads to massive waste of space, in some cases over 50%). JFS attacks this by allowing fragmentation of logical blocks into smaller units, as small as 512 bytes (this is sector size on harddrives and it is not possible to read or write less than 512 bytes from/to disk). However users should be careful because fragmentation incurs additional overhead and hence slows down disk access. I would recommend using fragments smaller than 4K only when the users know for sure that they will store very large amounts of small files on the file system.

The entire JFS volume space is subdivided into allocation groups. Each allocation group contains i-nodes and data blocks. This enables the file system to store i-nodes and their associated data in physical proximity (HPFS uses a very similar technique). The allocation group size varies from 8MB to 64MB and depends on fragment size and number of fragments it contains.


As the name of JFS implies, journaling is a very important feature of this file system. It should be noted that journaling is actually independent of JFS's structure described above. The journaling technique has its roots in database systems and it is employed to ensure maximum consistency of the file system, hence minimizing the risk of data loss - a very important feature for servers, but even home/SOHO users hate to lose data.

JFS uses a special log device to implement circular journal. On AIX, several JFS volumes can share single log device. I'm not sure this is possible on eCS, each JFS volume (corresponding to a drive letter) has its own 'inline' log located inside the JFS volume - its size is selectable at FORMAT time.

It is important to note that JFS does not log (or journal) everything. It only logs all changes to file system meta-data. Simply speaking, the log contains a record of changes to everything in the file system except actual file data, ie. changes to the superblock, i-nodes, directories and allocation structures. It is clear that there must be some overhead here and indeed, performance may suffer when applications are doing lots of synchronous (uncached) I/O or creating and/or deleting many files in short amount of time. The performance loss is however not noticeable in most cases and is well worth the increased security.

The log (or journal) occupies a dedicated area on disk and is written to immediately when any meta-data change occurs. When the disk becomes idle, the actual file system structure is updated according to the log. After a crash, all it usually takes to restore the file system to full consistency is replaying the log; i.e. performing the recorded transactions. Of course, if a process was in the middle of writing a file when the system crashed or power died, the file could be inconsistent (the app might not be able to read it again), but you will not lose this file nor other files, as is often the case with other file systems.

File System Comparison

The best comparison found of the various file systems available for eCS is in the installation manual supplied with the OS. Below is the chart from this manual below in table form.

Characteristic Journaled File System (JFS) 386 High Performance File System (386HPFS) High Performance File System (HPFS) FAT File System
Max volume size 2TB (terabytes) 64GB (gigabytes) 64GB (gigabytes) 2GB (gigabytes)
Max file size 2TB (terabytes) 2GB (gigabytes) 2GB (gigabytes) 2GB (gigabytes)
Allows spaces and periods in file names Yes Yes Yes No (8.3 format)
Standard directory and file attributes Within file system Within file system Within file system Within file system
Extended Attributes (64KB text or binary data with keywords) Within file system Within file system Within file system In separate file
Max path length 260 characters 1) 260 characters 260 characters 64 characters
Bootable No 2) Yes Yes Yes
Allows dynamic volume expansion Yes No No No
Scales with SMP Yes No No No
Local security support No Yes No No
Average wasted space per file 256 to 2048 bytes 256 bytes 256 bytes 1/2 cluster (1KB to 16KB)
Allocation information for files Near each file in its i-node Near each file in its FNODE Near each file in its FNODE Centralized near volume beginning
Directory structure Sorted B+tree Sorted B-tree Sorted B-tree, must be searched exhaustively Unsorted linear
Directory location Close to files it contains Near seek center of volume Near seek center of volume Root directory at beginning of volume; others scattered
Write-behind (lazy write) Optional Optional Optional Optional
Maximum cache size Physical memory available Physical memory available 2MB 14MB
Caching program None (parameters set in CONFIG.SYS) CACHE386.EXE CACHE.EXE None (parameters set in CONFIG.SYS)
LAN Server access control lists Within file system Within file system In separate file (NET.ACC) In separate file

JFS Implementation

JFS has been implemented in eCS in two pieces. Basically we have already covered the first. This is the Installable File System (IFS) providing both access to the storage and support of eCS semantics such as functional behaviour, error returns, and coexistence with other IFS implementations of FAT and HPFS. The only item we have left out is the IFS statement itself. The JFS version of the IFS is as follows:

IFS=pathname [/CACHE:][/AUTOCHECK:drive[drive...] /[L:OFF|L:synctime,maxage,bufferidle]]

JFS initialization parameters
Parameter Description
pathname Specifies that pathname of the JFS IFS
/CACHE:<size in kilobytes> Specifies the size of the JFS buffer cache in
Kilobytes. By default, this size is set to 12.5
percent of real memory.
/AUTOCHECK:drive[drive...]] Specifies a list of JFS file systems, identified
by drive letter, to be included in automatic
recovery by CHKDSK at the time of JFS
initialization. If an asterisk (*) is specified
instead of a drive letter list, all JFS file
systems will be included in automatic
recovery during JFS initialization. If any drive
letter is preceded by an arithmetic plus sign
(+), CHKDSK will perform a full integrity
check on the drive even if journal log replay
has restored the drive to an apparently
consistent state. If the list of drive letters ends
with a plus-asterisk (+*), CHKDSK will perform
a full integrity check on all JFS file systems
not specified in the list even if journal log
replay has restored them to an apparently
consistent state.
/L:OFF Specifies the lazy write parameters in
seconds. OFF forces all to be synchronous.
/L:<synctime,maxage,bufferidle> Synctime is the interval at which the sync
thread runs, default=32. Maxage is the
longest time that a modified file is kept in
cache, default is synchtime*4. Bufferidle is
the time indicating a "recent" change.
Changes newer than this value are not
written unless the last write was older than
maxage, default is Min(1,synchtime/8)

JFS Utilities

In addition to the parameters of the IFS statement, LVM also provides a set of utilities. WARNING: Some of these utilities can be hazardous to your data if used incorrectly. For safety's sake, back up your data before using them.

Here is a list of the JFS utilities, and a brief description of each.

When used on a JFS drive, CHKDSK accepts the additional parameter "/B" (without quotes) which causes bad block processing. Unlike other CHKDSK parameters, "/B" is used when the file system is active, makes bad blocks permanently unavailable, thereby removing them from the LVM fixed length bad block list.

When used on a JFS drive, FORMAT accepts the following additional parameters:

  • /BS:n, where n is the block size in bytes to use for the file system.
  • /LS:n, where n specifies the size of the journaling log to create in megabytes. The default is 0.4% of the file system size.
  • /S, which specifies the file system created should support sparse files. The default is dense files.1

DEFRAGFS [/Q] drive
As its name implies, this utility defragments a JFS's volume's free space. "Q" indicates "query" and, if specified, returns the drive's current status, and performs no defragmentation activities.

EXTENDFS [/LS:] drive
This utility is used after a volume has been enlarged using LVM to adjust the JFS file system to fit the volume. The optional /LS parameter indicates the size of the journal log to be created. The system will automatically perform a reboot if one is required.

Undocumented. This utility queries the settings of the cache, and can be used to set its lazy write parameters.

Undocumented. Diagnostic tool that shows a formatted log of the last CHKDSK process.

Informazioni sul prodotto Supporto Comunità Sviluppatori Scaricamenti Dove acquistare Chi siamo