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: Time for JFS has come (Part I)

DATE: 2003-09-02 21:12:55

AUTHOR: Pavel Shtemenko

What does JFS stand for?

JFS is an abbreviation for Journal File System. Journal means that all changes which are not committed on a disk, have been recorded in a special place on a disk named journal and in case of a fault could be restored without troubles (otherwise JFS has transactions). For example, in such file systems (FS) as HPFS, FAT and the rest of other non-journaling file systems, data in files which have been opened for writing in case of a fault would be lost. I must remark, that the presence of a journal has a very indirect influence on the file system performance.

What is a niche of JFS? What role does it play for industry? Is that a file system designed for servers or it can be used on eComStation?

The role is huge ;-) JFS is a file system for common purposes. JFS is faster than HPFS (even FAT aren't worse to compare), cache in JFS is a file oriented (file level caching in opposite to HPFS cache) and cache can have a big size which is important with the current level of RAM chips prices. For server implementation JFS still has some drawbacks in comparison to HPFS386, but JFS has open sources, which we can't expect for neither HPFS386 nor for HPFS. Usage of JFS in eComStation rather as in other versions of OS/2 is up to you, for the sooner you install it on your system the sooner you will sense all advantages of this file system.

What do you mean talking about JFS's drawbacks for servers? How do they affect such applications as Lotus Notes and DB2?

In general, all applications such as DB2 use all resources OS is able to provide - "in full throttle". In my opinion, in OS/2 those applications don't utilise all benefits of JFS, but I'm glad to see that many of APARs (fixes for OS/2), published some monthes ago, intend to fix this situation.

Can I migrate to JFS completely?

Completely isn't possible yet, but it is only a matter of time. Bootable JFS project is completed and should be released in the next version of eComStation. At the moment users install small HPFS partition for boot and the main lamp of information store on JFS.

Can you unveil the JFS unstableness myth? Till now somebody repeats that with Russian (different from English) filenames in a root directory, all data on a disk could be lost.

An absolutely reliable file system hasn't yet been created ;-) FS reliability is a combination of fault-tolerance and availability of specialised software for FS fixing. It is better to speak about a probability of data loss on JFS. From this point of view, JFS has very low such probability, i.e. there is only a few problems that have been reported since October 2001 version and the utility JRescuer for data salvage from "died" JFS partitions is now available.

What about Russian filenames - it is a common place for bugs for IBM developers, who are unaware that there are other countries except USA in the world ;-) In JFS all filenames are stored in Unicode. In early versions of JFS Unicode wasn't supported in full height, so, the person responsible for disk check utility (UJFS.DLL ) forgot that names are unicoded and compared them as plain CP866 codepage (current codepage), as it was in previous versions of OS/2. This bug was fixed and all UJFS.DLL after July 2001 no longer had this defect.

Where can I take utilities for JFS?

JRescuer can be used to recover deleted files too. There is other way to keep data - add SET DELDIR= statement in your CONFIG.SYS and use OS/2 system undelete utility.

Can I sleep peacefully if an electrician plays with electricity? Can you describe approximate algorithm for a recover after a crash?

Personally, I sleep peacefully ;-) Algorithm... Well, usually nothing happens and replication goes right. If check disk phase doesn't pass, the first you may do - to use program ISJ and suppress full-check flag for broken partition (after you rescued all data I urgently recommend to reformat this partition). If that cure didn't help, you must take data rescue utility JRescuer. I myself, when in 1999 first beta of Aurora became available, made several stress tests, while test program was doing multiply read/write operations, I did either:

• pressed a Reset button;
• switched off computer power;
• disconnected disk power;
• detached disk interface cable;

and inspected results.

All these four tests JFS passed well, in the worst case the last written file was empty with a zero length. JFS's malfunctions I have seen - once a BAD block appeared inside a superblock area, that occasion induced ISJ utility birth. Other case was very strange - after I replaced my 6 Gb disk with 10 Gb new one in my computer the phase 3 of CHKDSK was looped infinitely (I suspect that was a problem with LVM, not JFS), ISJ also was helpful. The only way I know "to kill" JFS partition is to erase all superblocks, but even in this case data could be restored, specialised utility development is in a progress.

Typical situation. For example - CHKDSK after a reboot lasts for along time and then reports that it can not accomplish something and partition isn't available. In this case we use ISJ and reset full checking flag. If even though, after a reset flag operation, disk is still unavailable it is essentially to use JRescuer and following disk format is inevitable.

ISJ usage is a piece of cake - ISJ -C, and it goes to search all existent JFS partitions on your disks and when it finds it, then prompts you to reset full checking flag on a particular partition, partition you need you can recognise by its disk-label. Next reboot, usually you get your damaged partition back. Of course, it would be better to backup data from this disk and reformat it. Program for rescuing files is also simple - JRescuer D:, where D: is a drive letter to rescue from, everything from this disk will be hauled and written into the current directory, directory where JRescuer has been started (you should have extra space on other OS/2 partition to rescue data from died JFS, or the situation becomes more complicated if you don't have a disk space to save rescued files, this is your home task, translator's note ;-)

OK, sounds good. To install JFS it is enough just to format a new partition as JFS, isn't it? Or, probably there are tools to convert existent partition to JFS? Are there any limits for a partition size?

There are no tools to convert existent partitions and hardly likely will be, although, any kind of tools could be created. For sure there are limits for partition size, they are: about 10 Mb minimal size and 2^^63 bytes maximum (2 Terabytes). I recommend you don't be lazy and use long format, for example FORMAT T: /FS:JFS /L and don't alter default cluster size (4096 bytes). I don't intend to dig into mechanics how it works but the major amount of JFS malfunctions are connected to short format usage and altering cluster size.

After file system installation is it necessary to adjust something or does everything works without any intervention?

In general, adjustment is not necessary. Although in the READ.ME file from Aurora beta 2 was written that DEVICE=UNICODE.SYS statement should be before IFS=JFS.IFS (in your CONFIG.SYS). Besides the fact that in normal boot sequence DEVICE statements are processed after IFS ones... But JFS uses unicode kernel functions and I doubt that kernel parses NLS files itself.

Are there any tests for file systems benchmark? Which characteristics are important?

The most common way - to copy bunch of large files and to copy many small files, or better to do that simultaneously ;-) Other tests don't reflect real system load well.

Linux guys always humiliate JFS. What is your opinion? Otherwise for what sake did IBM make JFS for Linux for?

Hm, I've read only a single comparison, then I wrote to the author, who appeared not an author at all, just a pedestrian... Firstly, linux guys, as always, benchmark systems incorrectly, mostly of them compare which FS kernel's cache is more effective. For instance - EXT2 under OS/2 is a real sucker... but under Linux is quite usable FS. Let me explain why their benchmarks are incorrect conceptually. JFS works the following way “file->cache+recording in a journal->journal replication->disk”, in Linux version of JFS there is no cache even for reading (supposed that kernel should perform caching itself), certainly the most performance critical part is a pair "cache+recording in a journal" . So, for the same reason EXT2 in OS/2 (absence of cache on a kernel level) is slower than even FAT. Well, we can benchmark systems on the "linux way" - install WSeB, add EXT2 or any other Linux FS driver and measure a speed... I guess results could be predicted, they are obvious.

Regarding IBM and Linux... Frankly I'm puzzled for what reason IBM made that, but regretfully this is neither the last nor first incomprehensible act of IBM. Although we have some bonuses, IBM opened source codes for JFS OS/2 ;-) I've been watching the JFS evolution in Linux... for the present moment something has been only removed and nothing has been added, first thing which was removed is cache, in contrary to JFS in AIX, which has cache despite being unix alike OS.

What features does JFS have?

First is a very fast check disk procedure, with one exeption, fast in case of right journal replication, otherwise...

EA (extended attributes) support, besides that IBM reboots point that NFSD/2 connected to JFS directly (i.e. has GID/UID support), I haven't tested that yet, JFS really stores those GIDs and UIDs in a file/directory description area on disk up to the present time.

File cache size is not dynamic, cache size is set in a configuration, but JFS allocates extra memory from kernel for its functioning. Efficiency can be estimated in the standard way - by the number of cache hits, JFS offers such sort of tools.

Well... are they the only features? I mean a journal and a big cache size.

Hm, what other features did you expect for FS? The rest depends on programs. FS has to be fault tolerant, doesn't interfere with other parts of OS, has to be fast and flexible to the hardware configuration. Theoretically if you create one partition in 20 Mb size and set a cache size in 20 Mb you will get RAMdrive with a disk mirroring... Moreover, JFS has no file number limit, no filename length limit,... no file size limit... those features are up to OS which uses JFS.

Does JFS has symlinks or will it have them?

JFS has hardlink support, theoretically it should work inside one FS (among several partitions), for instance if you've got 3 JFS partitions, hardlinks should work among these 3 partitions. Symlinks... better use TVFS ;-) OS/2 isn't tailored to symlinks, to support symlinks properly it is necessary to rewrite DOSCALL1.DLL or kernel... Strictly speaking in JFS OS/2 hardlinks don't work either. But it is not a tough task, as the file system itself has everything for that.

Well, Linux knows JFS. What about Windows or other operating systems?

AIX is aware of JFS ;-) I know nothing about other OSes. Windows... M$ IFS DDK is a big secret (precisely not a secret, but costly enough to buy even for Western companies). I think Windows badly needs JFS, because to the present moment it doesn't have a good file system.

What will be after JFS? Or JFS is the last edge?

I am not an oracle and I don't make or accept predictions of such extent ;-) It is hardly possible IBM would do something for OS/2 and a choice isn't too rich, only in Unix they try to stir their butts and to invent something. More likely that M$ approach will win - multiply MegaGz to MegaBucks and don't invent something really new and useful.

What other file systems does OS/2 have? Would it be easy to migrate from Windows, BeOS or Mac to OS/2?

OS/2 is shipped with three standard file systems support - FAT, HPFS and JFS. Except that, there is a third party VFAT IFS which works well, and there is an EXT2 driver, which works bad. I've already mentioned that FAT is a very slow and unreliable file system, but it has a plenty of various utilities. HPFS is faster and much more reliable then FAT, but it loses to JFS at performance although being comparable in reliability. In case of migration neither JFS nor HPFS will add any trouble, sooner new users would be amazed with LVM with its possibility to extend JFS partitions "on fly", what is very important for servers. Together with that I want to admit that if LVM could decrease partitions "on fly" it would be considerably better... For new users' migration to OS/2 we don't need file systems, what we need are new programs.

• Author: Pavel Shtemenko
• Questions by: Eugene Gorbunoff
• English translation by Andrei Porodko
• Original russian edition of article was published in Summer, 2002.

Comments:

Porro 2003-09-25 15:54:33

I don't believe my eyes ! ;-) Not even a year has passed ;-)

Comment this article.

Your Name: Your E-Mail: CODE:
Your Comment:

eComStation is fully compatible with IBM OS/2 Warp, Read more about compatibility with IBM OS/2 Warp