OS2.GURU - JFS recovering methodologyOS2.GURU - JFS recovering methodology

Welcome to eComStation.RU site!

Select your language: Russian English Deutch Spanish Italian Portuguese Czech Polish French

Frequently asked questions and answers:


+7-981-8529467 (Санкт-Петербург)
ru · en · de · es · it · pt · cz · pl · fr
OS/2 is a greatly different operating system for PC (ArcaOS, eComStation, IBM OS/2 Warp)
Applications, news, reviews, support of users, hardware, questions and answers.
      What is OS/2?NewsInstallUpdateUsageFutureCommunityBuy    
(Map of the site)

Database of OS/2 compatible hardware




For developer:

(Пайпы программ)





(Барьеры и решения)


(Применение в науке, лаборатории, ..)



New eComStation:


(Ссылки на другие сайты)

(Картинка дня)

OS/2 artefacts:


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)

JFS recovering methodology

TITLE: JFS recovering methodology

DATE: 2003-07-31 13:13:42

AUTHOR: Pavel Shtemenko


"What To Do?" (c) Chernyshevsky

This article doesn't claim that JFS crashes every hour, but it suggests "What To Do" if the crash occurred. In our humble opinion, absolute reliability doesn't exist, in particular, that's true for FS as well as for thermodynamics laws. Knowing about possibility to lose the information and taking preventive measures are different thing. The author believes that FS reliability consists of:

  • crash probability
  • recovery probability

We won't provide supporting formula or graphs, they're quite useless. Instead we'll try to answer the most important question for the user experienced JFS crash: "What To Do?".

Part 1

I won't consider question "why could JFS structure crash?" leaving it for someone's Ph.D. thesis. Assume that the crash happened. Typical case: `chkdsk' fails reporting some errors, volume is not mounted. "What To Do?" First of all, don't panic and don't blame JFS for instability. I assure you that any other FS has at least the same probability to crash. Realize that your disk still keeps the information although it's not available for the system. So, calm down. As the last option you can always use low-level disk editor to extract the information. We consider how to lighten the data recovering from semi-dead JFS volumes.

Part 2

So, we have unreadable JFS volume and a question "What To Do?". First you should try the system tools (excluding `format', of course) to get it back to life. When they don't help, it's time to try ISJ utility [download me]. It forces `chkdsk' not check the disk allowing JFS driver to mount ruined volume. Beware of possible system traps, but that's an opportunity to partially copy data from the volume. Copy your data until you found the piece that causes a trap. According to Murphy's Laws, it will contain the most important information. Don't worry, hopefully that's not fatal (remember, you still have disk editor as an option). But ISJ cannot help you anymore. Running ahead, point out another way to use ISJ. `chkdsk' is a program, and might have bugs preventing JFS volume from mounting. ISJ allows to set up "don't check" flag and then to remount the volume avoiding `chkdsk':

Jrescuer N: /R

If it succeeded, you'll get the volume mounted (but beware of possible system crash because of ruined FS structures).

Part 3

Now we are close to the last option (disk editor), very close, but... ISJ is not the only tool, there is an utility called Jrescuer [download me]. Important feature is that it doesn't require mounted JFS volume but just a volume letter (this requirement can be removed on registered linux user request), and ujfs.dll from any JFS driver version. Make sure ujfs.dll is available through LIBPATH before running Jrescuer. Now run:

  Jrescuer N:

where N is volume letter

This command recursively extracts data starting from the root directory of JFS volume to the current directory. If everything is extracted, you're lucky! But it's possible to meet BAD SECTORS at some important places (remember Murphy's Laws). Don't panic (you have disk editor), print out the root directory listing as follows:

  Jrescuer N: /D=1

The listing looks like:

InodeNumber0 Name0 Flag0
InodeNumberM NameM FlagM

InodeNumber - number that will be used later, remember it if needed
Name - file/directory name to decide if it's important for you
Flag - directory indicator: "DIR" for directory, and space otherwise

Now choose the directory with important data to rescue, and run

  Jrescuer N: /I=InodeNumber

to extract the data from directory and all subdirectories to the current directory. All is ok? Great! If not, run

Jrescuer N: /D=n 

where n is maximum recursion depth

to locate where Jrescuer fails. Suppose it's in \foo\foo1\foo2\...\fooM directory. Impossible to extract the whole directory? Let's try to get separate files like \foo\foo1\...\fooM\fileWithSize0. Just run

 Jrescuer N: /G=\foo\foo1...fooQ\fileWithSize0

If it's possible, Jrescuer will extract SomeFile for you. But it might face Murphy's Laws again, and you'll get nothing. Then there are two options:

  • recall disk editor
  • write to Jrescuer author, and maybe he will fix the problem in the next release.


Those, who wants to recover the data, learn JFS structure. Those, who didn't get anything, replace "disk editor" with "white monkey" and read again. In general... Jrescuer was written for and tested on ruined JFS, whose owners were forced to accept my experiments. Personally I had ruined JFS only once, and it gave born to ISJ.


  • Nicholas Poendaev - first real tester of Jrescuer
  • Alexander Krapivin - for useful suggestions and bugs catching
  • Achim Hasenmueller - for not accepting Jrescuer to VPC exchange, and hence allowing its further development
  • All the other anonymous beta-testers.

Short FAQ

Q: Is there a chance that ISJ doesn't help?
A1: Yes, usually it happens when the journal cannot replicate for some reason
A2: run ISJ and read usage

Q: Is there a chance that Jrescuer doesn't help?
A1: Yes, if there in no clusters with data

Q: Is it possible to use those utilities for Linux/JFS
A1: Sure, if you assigned a volume letter before the crash, or have persuaded the author to remove the letter requirement.

JRescuer - is a product of eCo Software, (c) Pavel Shtemenko. You can purchase the license at Mensys.nl

Test the program:

Virtual machine for eComStation? How to run eComStation inside virtual machine? (Read more..)


David Adolphson
2004-07-02 18:04:05

I'm getting this error on about half the files that I'm trying to recover with JRescuer:

Internal error: devices.c(491): error 87

> InternalXAD: error reading xtpage

The files that give this error get "recovered" as zero byte files. Can you fix this?

Pavel Shtemenko
2004-07-02 18:14:48

Yes, write to me and I send to you fixed version

David Adolphson
2004-07-05 18:37:27

Thanks Pavel, please email the fixed version to me at [e-mail] thank you. Better yet, post it to hobbes or put some other public site.

David Adolphson
2004-07-05 18:41:47

I now see the version linked on this page is the new version, it appears to work. I'll try it out and let you know how it goes... many thanks!! :)

David Adolphson
2004-07-05 19:16:02

Sorry, I do not appear to have your new fixed version. Version 2.4 of your program gives the error I show above on many files. I tried version 1.4 (the old version linked on this article) and the error does NOT occur, but 1.4 does not work when trying to "recover everything". Please fix.

David Adolphson
2004-07-05 19:30:17

I just got the "fixed" version but it has a bigger problem:

[T:\]c:\TOOLS\jr\jrescuer q:


Rescue files from damaged JFS V 2.4.

Product of eCo Software, (c) 2001, 2004 Pavel Shtemenko

Other eCo Software products:


RegFile present

Programm registered to DavidAdolphson


The process has stopped. The software diagnostic

code (exception code) is 009B.

2004-07-11 11:12:37

I have same problem exactly. Current version leaves alot of 0 byte files from the listed error. Old version from this page does not tell any error, but it does not write any files at all!

Is there an archive of other versions?

2004-07-11 23:24:18

Pavel thanks for your e-mail, now it seems to be working.

David Adolphson
2004-07-22 00:28:50

Any chance that you might be able to fix OS2DASD.DMD to support disks greater than 502GB?

Pavel Shtemmenko
2004-07-22 09:22:50

Write to my e-mail for detailed your problem. Or bell to nick [Pasha] at EfNet or EcsNet IRC. As I mean, up2tb.flt not worked with your devices?

Vladimir Solovyov
2004-07-22 09:54:08

2 David Adolphson:

Did you try this :



Martin Tepe
2004-11-24 05:52:50

Any chance this might work on an AIX disk with JFS and logical volumes, where the superblock is unreadable - hard disk error.

David Adolphson
2005-07-18 00:04:18

I'm running jrescuer against a 30GB JFS drive and it prints out a ton of lines that say "##### NotConventions" where ##### is some number. What does that mean?

Pavel Shtemenko
2005-07-18 00:18:42

This say - "current file name can't convertion from unicode to your current codepage". Try get file as:

Jrescuer x: /u=inode (or i=inode if this inode is DIR)

Keith Gale
2005-08-09 00:19:14

My computer support person purchased Jrescuer last week to recover from a crashed JFS volume. The program has been working great until now. I keep getting the following error:

GetXtree: Error create file Restored.From.JFS, rc=5 action=65535

Could you please tell me what has gone wrong? Thanks!

Pavel Shtemenko
2005-08-09 00:39:36

It mean, what Restored.From.JFS is existing in this directory. cd to another dir and try operation.

Keith Gale
2005-08-09 00:59:14

Thanks for the quick response. I have been renaming the Restored.From.JFS file to another filename each time. The only two files in the directory are the executable and the key file. I wasn't sure if there was a limit to the number of files to recover. I have done this about 50 times today. Everytime it would create a Restored.From.JFS file and I would rename it to data#.ext

David Adolphson
2005-08-23 03:27:57

I'm still getting "##### NotConventions" where ##### is some number as output, and I have unicode.sys loaded correctly, and my codepage is set correctly. Is there something else I need to add to the boot floppys to get this to work?