OS/2 eZine - The Best OS/2 Reading Anywhere!

16 October 2001

JFS Cookbook

You don't like JFS? You don't have the right Recipe! :-)

Everyone has heard from IBM that JFS is a cool journaled file system that came to OS/2 from AIX. Taking into consideration the potential and abilities of IBM, it is logical to believe in its super reliability.

But our experience and tests of JFS show this file system can be used without fear of losing data only if several simple but important rules are observed.

Terminology - IFS and DLL

We will touch upon the internal organization of JFS in OS/2 so that you can understand better our actions if you, for instance, have never looked into the \OS2 directory of your system disk.

All the work with the file system is done by two files \OS2\JFS.IFS and \OS2\DLL\UJFS.DLL. There are also files JFS.MSG and JFSH.MSG where descriptions of possible errors while working with JFS are kept. But they are not interesting for us now.

JFS.IFS is actually a file system driver. It controls all the operations with JFS volumes at a low level.

UJFS.DLL is a library of standard auxiliary functions to work with a JFS volume. It contains, for instance, functions for formatting a volume or checking information on it. Actually, the programs format.com and chkdsk.com only call functions from UJFS.DLL (if the file system of the operating volume is JFS. If it is HPFS, UHPFS.DLL will be used instead.

Such separation makes possible using combinations of IFS and DLL files from different issues of JFS in order to operate with a minimum of problems.

The Notion of 'version of JFS'

What is meant by "version of JFS"? This is a combination of JFS.IFS and UJFS.DLL files from one archive/fixpack or OS/2 release.

We examine JFS from WSeB release, official fixpacks XR_E001, XR_E002 and all the versions that went through IBM's Testcase server.

Why is JFS Good?

We believe that if you are reading this article you have already realized that JFS is a good and quick file system. Much is written about it, so we are not going to praise it here.

Problems and Solutions

We will describe JFS' advantages here, but later. Now we are going to talk about drawbacks and how to avoid them.

Moving Files and Directories to \lost+found with Filename Corruption

The saddest thing that Russian JFS users (probably not only Russian) faced is problems with chkdisk if you have files with names containing national symbols.

Digression: Names of files in JFS are kept in Unicode (two-byte code.) The error was in the processing of the high byte of the first symbol of each file name.

If it was not zero (it is not in all code pages but American) then while checking the disk with chkdsk there was an error on such a file as IBM programmers used the function memcmp, not the highly recommended unistrcmp.

That meant that if a file started with Russian "A" (code 07 80h), not with "A" US Codepage (00 80h), you will surely have problems.

In fact the problem was that all the subdirectories (with files inside) were moved from the place where the file with national symbols was kept to the \lost+found directory, partly losing their initial names.

This error was corrected in FreeJFS 1.1, and after our bug reports, in IBM JFS from 22/06/2001 that was released only on IBM Testcase. As far as we know, JFS in eComStation is dated earlier and most probably the error is not corrected there.

We stopped spreading FreeJFS 1.1 because of problems and corrections in IFS.

Now the next version of FreeJFS is being developed where all the errors will be taken into consideration and some new functions added.

If you may have files with symbols different from codepage 850 in names, we recommend you to use UJFS.DLL from version 22/06/2001/Testcase.

More about National Symbols

If you think that these are all the problems with national symbols, alas it is not so. There is another IBM mistake: working with Unicode functions is incorrect before the Unicode.sys driver is loaded.

Unfortunately, OS/2 installers do not check this important condition by themselves, so most often the UNICODE.SYS driver is loaded by Config.sys after loading JFS.IFS.

In spite of the fact that IBM added fuctions for working with Unicode directly into JFS.IFS driver starting from WSeB Fix1 (XR_E001), we can not absolutely guarantee that they corrected unicode.sys.

So, we come to the following rule of setting JFS: After installing OS/2 with JFS, check that Unicode.sys is loaded in config.sys before (higher in the file) JFS.IFS.

Lazywrite

Write cacheing was not included at all in the beta and WSeB releases of JFS. You could use the "/LAZY" switch but write cache did not work.

You will probably remember a long process of deleting lots of files. This was corrected rather quickly - cache was included in the first fixpack (XR_E001), though there is a small disadvantage - the write cache is still being fixed.

The advantages of lazywrite are obvious. The disadvantages of lazywrite's glitches are that after hanging/trapping of the system and processing chkdsk, all the files that were open by the system at the moment of fail have a zero file size.

Probably the same occurs with the files if the information about their recording did not come into the journal.

What can be recommended here? If you can not provide 100% guarantee of correct System Shutdown or Ctrl-Alt-Del you'd better use JFS.IFS from the WseB release (where lazywrite is just not included.)

It is not recommended to use a newer JFS.IFS with switched off Lazywrite in its configuration file as not all fragments of code referring to lazy write actually switch off.

About Running CHKDSK

We would like to dwell on checking JFS volumes with program CHKDSK.

Generally speaking, checking JFS disks is necessary only in difficult situations, for instance, when the system has trapped. That's why we don't recommend you start chkdsk often just to check if your file system is OK.

Moreover, CHKDSK is very harmful if started not from CONFIG.SYS at boot but after boot during real work with live data.

The problem is that chkdsk does not use the data from the JFS log on mounted volumes, and the full replication of the log occurs only at system boot.

This means that it is correct to start chkdsk only from CONFIG.SYS at system startup when the JFS volume is not mounted in the system.

So, if you want to check the structure of JFS volume you can do as follows:

Using utility ISJ from FreeJFS.Tools set the dirty flag of the necessary volume to "repair check".
Make sure that the letter of the volume is indicated in switch /AUTOCHECK (or "*").
Reboot OS/2.
When starting the system, before the volume mounting, chkdsk will be started and the volume will be fully checked.

Rules for Cooking with JFS

So, to conclude, we think JFS is worth using, but you should observe the following rules:

Unicode.sys in config.sys should be loaded BEFORE jfs.ifs
Use UJFS.DLL from 22/06/01 from Testcase, if there are national symbols in file names.
If you are not sure your system is resistant to hanging and traps use JFS.IFS from WseB release.
Don't start CHKDSK on mounted JFS volumes while the system is working. If you want to check it - mark "repair check" on the necessary volume and it will be checked at the next start of the system.
Get the ISJ utility and boot into OS/2 without the JFS.IFS driver if you have JFS from xr_e001 or later and you are going to switch hard disk from one IDE channel to another (or another computer.)
Don't keep ISJ on JFS volume, otherwise if you have problems with JFS you won't be able to use this utility.

We hope our advice will be helpful for all OS/2 users. If you have questions or comments don't hesitate to write us at freejfs@os2.ru (mailto:freejfs@os2.ru).

ISJ Utility

ISJ - Information & Set for JFS Utility. By Pavel Shtemenko. It allows you to set the dirty flag on JFS volumes to "clean", "standard" or "repair" mode.

Usage:

isj.exe -dn [-c|-s|-r] [-2] [>file]

Where,

-d drive number

n == HDD Number begining from 1 (default 1)

-c clear check (set reboot check to "never")

-s standard check (set reboot check to "standard check")

-r repair check (set reboot check to "repair check")

-2 use 2nd superblock

JFS.IFS Switches in CONFIG.SYS

Syntax of switches:
IFS=x:\OS2\JFS.IFS [/SWITCH:VALUE] [/SWITCH:VALUE]

where "x:" Specifies the drive letter of the partition from which the OS/2 program is started.

for example,
IFS=X:\OS2\JFS.IFS /AUTOCHECK:DRIVES /CACHE:SIZE /LAZY:[Off|synctime,maxage,bufferidle]

Allowed aliases for switches:

/AUTOCHECK /A

/CACHE /C

/LAZY /L, /LW, /LAZYWRITE

For example, "/AUTOCHECK:*" and "/A:*" are equivalent.

/AUTOCHECK

Specifies a list of drive letters to be automatically verified by the CHKDSK command at system startup if JFS detects that the drive may have been shutdown unexpectedly.

The drivelist value is a string of letters indicating the JFS drives in the workstation. The drive letters are not separated by commas or spaces. If any drive specified is not a valid JFS drive, the drive is not checked.

Example: /A:DEW - will check volumes D:, E: and W: /A:* - will check all found JFS-volumes

/CACHE

Specifies the amount of memory, in kilobytes, to use for the JFS cache.

Example:
/C:8192 - set JFS cache to 8 MBytes of RAM

/LAZY

enables or disables write cache.

/LAZY:OFF

disables write cache. It forces asynchonous writes to be immediately initiated (synctime=1, maxage=0, bufferidle=0)

/LAZY:synctime,maxage,bufferidle

enables write cache with the following parameters:

synctime the interval at which the sync thread runs (in seconds) default value - 16

maxage is the longest time in seconds that a frequently modified file is kept in cache. default = synctime * 4

bufferidle is the time in seconds indicating a "recent" change. Changes newer than this value are not written unless the last write was older than maxage. default = MIN(1,synctime/8)

Examples

IFS=C:\OS2\JFS.IFS /L:32
synctime = 32, maxage = 128, bufferidle = 4

IFS=C:\OS2\JFS.IFS /LW:5,20,4
synctime = 5, maxage = 20, bufferidle = 4

Pasha Shtemenko (mailto:freejfs@os2.ru) Pasha Shtemenko is a former PDP11-40 sysadmin & programmer, he started programming under OS/2 in 1995. Special interests: system programming and JFS scrutiny.

Konstantin Okounkov (mailto:freejfs@os2.ru) is the coordinator of Russian Team OS/2 and an editor of the OS2.Ru (http://os2.ru) site. He is also a member of some OS/2 projects and OS/2 user/programmer since 1995. He believes that the best computer game is OS/2 itself.

Thanks to Irina Okounkova for translating this article to english.

This article is courtesy of www.os2ezine.com. You can view it online at http://www.os2ezine.com/20011016/page_6.html.