|
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
Introduction
"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
where
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.
Epilogue
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.
Acknowledgments
- 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
A2: RTFM! And THINK!
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
Comments: 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:
JRescuer
Rescue files from damaged JFS V 2.4.
Product of eCo Software, (c) 2001, 2004 Pavel Shtemenko
Other eCo Software products:
[url]
RegFile present
Programm registered to DavidAdolphson
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
| Paul
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? | Paul
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 :
[url]
? | 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? | David Adolphson
2005-08-24 03:28:40 | I've read the recommendation in the FAQ concerning "##### NotConventions" and the answer is not sufficient. If "unicode is unable to convert name of file to system codepage" then how do I make it so that it CAN convert it? I get the "##### NotConventions" listing even when I run jrescuer against a working jfs drive, yet obviously JFS can get the file names okay... | Pavel Shtemenko
2005-08-27 07:34:09 | ##### NotConventions can be:
- if your unicode system not work right (this message will be in any file with NLS in filename)
- if filename is damage in physical disk | David Adolphson
2005-08-27 17:18:56 | > - if your unicode system not work right (this message will be in any file with NLS in filename)
I'm getting "NotConventions" on ALL files and directories, and 99.9% of them have only chars A-Z and 0-9 in their name.
> - if filename is damage in physical disk
I get "NotConventions" when running jrescuer on a working drive, so I know this is not the case either.
Could it be a bug in jrescuer?
| Pavel Shtemenko
2005-08-27 19:31:37 | >I get "NotConventions" when running jrescuer on a working drive, so I know this is not the case either.
Do you get all filename "not conversion" in work disk? Send to me pls listing from Jrescuer and list from dir. For one directory.
>Could it be a bug in jrescuer?
May be. Need to discavery. | David Adolphson
2005-08-28 18:04:58 | Okay, I will gladly help debug this problem. I will email you output of:
"dir z:"
"jrescuer z: /d=1"
copy of config.sys | David Adolphson
2005-09-22 23:09:54 | Has anyone been able to get jrescuer to work from a floppy disk or CD boot? I get NotConventions errors even with all unicode files loaded to my knowledge. | Lutz Geyer
2005-11-01 19:27:48 | Ok, jrescuer work like a charm.
But JUne looks more like April or May:
if I try to restore a deleted JFS-file, it only stores (repeatedly) some information in popuplog.os2:
11-01-2005 17:12:03 SYS3175 PID 0049 TID 0002 Slot 00a8
C:\T\JUNE.EXE
c0000005
160c219b
P1=00000002 P2=00000000 P3=XXXXXXXX P4=XXXXXXXX
EAX=00000000 EBX=00aa0030 ECX=00000000 EDX=00ae0200
ESI=00aa0030 EDI=000100cf
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:160c219b CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:00a79ddc SSACC=f0f3 SSLIM=ffffffff
EBP=00a79e20 FLG=00012206
JFSTOOLS.DLL 0002:0000219b
What shall I do?
Regards
Lutz
| Davorin
2006-12-01 21:23:19 | I copied jfs disk from my laptop to my PC over wired lan. Code page on the both computer is unicode 852.
After reinstalling my OS on the laptop, I tried to copy the all data back, but most of the files are unabled to open. When I edited some files, I see that it consist content of the other files ( pictures have parts of some text files etc.).
Is there a way to repair this files? |
Comment this article.
|
 |
IBM OS/2 Warp
|
