ArcaOS 5.0 Russian Russian ARCAOS exists and it's available since the middle of 2017. All versions are supported: 5.0, 5.0.1, 5.0.2. eCo Software is able release OS/2 LIP packages for any other language (German, Dutch, Brazilian Portuguese, Spanish, Sweden, etc)

TITLE: Overview of the JFS filesystem

DATE: 2005-05-08 20:38:05

AUTHOR: group of authors

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 (smaller than 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.

Journaling

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.

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 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.

CHKDSK
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.

FORMAT
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.

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

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

Comments:

...... 2005-05-12 04:38:20	. ... ...... .... "260 characters 1)"?
...... 2005-06-03 10:12:49	JFS ...... ... [url]

Comment this article.

Va e jmИno: VА  E-Mail: CODE:
VА  pЬМspЛvek:

Publish the success story of eComStation usage in business and office/home. Success stories