|
Upgrade ArcaOS to NeoWPS level
- Install original PNG icons drawed by designer, specialized at OS/2 adornation.
- Install eSchemes 2018 to change colors and buttons on desktop.
|
Time for JFS has come (Part I) |
TITLE: Time for JFS has come (Part I)
DATE: 2003-09-02 21:12:55
AUTHOR: Pavel Shtemenko
Please use online translator
go to http://translate.google.com
and request the translation of http://en.ecomstation./showarticle.php?id=94
to your language |
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.
Kommentare: Porro 
2003-09-25 15:54:33 | I don't believe my eyes ! ;-)
Not even a year has passed ;-) |
Kommentiere diesen Artikel.
|
