chkdsk on JFS
tho...@antispam.ham
reboot process, I received the following output:
] The current hard disk drive is: S:
] The type of file system for the disk is JFS.
] The JFS file system program has been started.
] CHKDSK Block size in bytes: 4096
] CHKDSK File system size in blocks: 29302552
] CHKDSK *Phase 0 - Replay Journal Log
] CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
] JFS0148: CHKDSK Unrecoverable error reading M from s:. CHKDSK CANNOT
] CONTINUE.
]
] JFS0148: CHKDSK Unrecoverable error reading M from s:. CHKDSK CANNOT
] CONTINUE.
]
] JFS0148: CHKDSK Unrecoverable error reading M from s:. CHKDSK CANNOT
] CONTINUE.
The drive was working fine before the reboot. Now I can't access
anything on the drive.
What is "M"? Is that supposed to be the name of a file, a directory,
or some data structure internal to JFS? I don't recall having any
file or directory named "M".
Is the only solution a reformat and restore from backup?
Peter Brown
Marty
Probably some garbled data causing the message to print gibberish.
Are there any chances that the "simultaneous" problems with your audio
and your hard drive are not coincidences? Any chance of IRQ/DMA
conflicts or the like?
As Peter said, I think DFSee is probably the only tool which could
recover you from here if it is not a temporal failure. You'd probably
need some expert supervision to get anywhere with it. Jan van Wijk is
usually glad to help out, as long as it takes, provided that you
register the software. Use extreme caution if you try to go at it alone.
If there is some form of IRQ/DMA conflict causing a temporal failure to
access this drive correctly, then it may be "fixable" by disabling some
devices (sound card seems a likely suspect) if no permanent damage was
done. In other words, it's possible that the hard drive's data is still
recorded correctly on the platter, but is being garbled as it is read
in. Slim hope, but non-zero probability at least.
Good luck.
--
[Reverse the parts of the e-mail address to reply.]
Karlheinz Schmidthaus
>
> Is the only solution a reformat and restore from backup?
>
What version of the JFS driver and utilities you are using?
Are you using bootable JFS?
Trevor Hemsley
And as a last resort, maybe you can mark the partition as not dirty using DFsee
or one of the Russian JFS utilities so that you can access the remaining content
and copy it off.
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
tho...@antispam.ham
> Are there any chances that the "simultaneous" problems with your audio
> and your hard drive are not coincidences? Any chance of IRQ/DMA
> conflicts or the like?
I can't imagine that there's any connection. Audio and the drive have
coexisted happily for years. I've had to reboot several times to
restore audio, and it's never had an effect on the drive before.
Marcel Müller
Trevor Hemsley wrote:
> And as a last resort, maybe you can mark the partition as not dirty using DFsee
> or one of the Russian JFS utilities so that you can access the remaining content
> and copy it off.
as far as I remember you can simply press Ctrl-Break when CHKDSK works
on a JFS partition. Seems that CHKDSK for JFS clears the dirty bit first.
Of course, this will not work in case of a boot time check. But it is a
good advise anyway to check nothing but the boot drive at startup. If
you do it later at startup.cmd it is faster by a factor.
Marcel
tho...@antispam.ham
> What version of the JFS driver and utilities you are using?
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
Vendor: IBM
Revision: 14.105
File Version: 14.105
Description: IBM OS2 JFS retail bld
05-01-01 6.32 6.417 0 ---- CHKDSK32.EXE
> Are you using bootable JFS?
No.
tho...@antispam.ham
> But it is a
> good advise anyway to check nothing but the boot drive at startup. If
> you do it later at startup.cmd it is faster by a factor.
Hmm, interesting idea. How much faster is it? The one disadvantage
that I can think of is that if any applications that the systems tries
to autostart reside on an unchecked partition, then they can't be
autostarted.
tho...@antispam.ham
> as far as I remember you can simply press Ctrl-Break when CHKDSK works
> on a JFS partition. Seems that CHKDSK for JFS clears the dirty bit first.
That doesn't work for me.
Marcel Müller
maybe they fixed it long ago.
Marcel
Karlheinz Schmidthaus
All JFS files including the ujfs.dll are from Jan. 2006? That is the
latest build from IBM.
Try DFSEE, it has many functions to check and repair JFS drives. And
additional the support by the developer is very good.
Marcel Müller
> Marcel writes:
>
>> But it is a
>> good advise anyway to check nothing but the boot drive at startup. If
>> you do it later at startup.cmd it is faster by a factor.
>
> Hmm, interesting idea. How much faster is it?
It depends on your system. If you have many physical disks and HPFS
volumes besides the boot volume it can be a factor 10.
If you have only one JFS volume it will be not that significant.
Look for lateautocheck on hobbes. It will schedule a job for each
physical disk to clean all dirty volumes on that disk (if any). The main
benefit is that checks on different physical disks can be done in
parallel with almost no performance impact. Furthermore chkdsk is
significantly faster when the system is up because it can use
significant memory for read caching. This may depend on the file system.
HPFS volumes are checked about 3 times faster when the system is up.
Because of that it can be faster to boot to command line with Alt-F1 F2,
(which usually does not have the autockeck entries for volumes formatted
after install), then do the chkdsk from command line and reboot.
> The one disadvantage
> that I can think of is that if any applications that the systems tries
> to autostart reside on an unchecked partition, then they can't be
> autostarted.
Correctly.
But I usually have no applications in the autostart that depend on data
on different volumes.
Marcel
m...@privacy.net
>Marcel writes:
Have you tried a CD boot and running chkdsk from there? I do this if I
have a trap/hang on my eCS 2.0 RC6a test unit using my eCS 2.0 RC6a boot
CD to either a full screen or the management console to run it.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
Steven Levine
at 12:08 PM, Marcel Müller <news.5...@spamgourmet.com> said:
>Look for lateautocheck on hobbes. It will schedule a job for each
>physical disk to clean all dirty volumes on that disk (if any).
Lateautocheck is useful for volumes that will not to accessed by anything
that starts automatically. For volumes that need to be autochecked
earlier, I use
CALL=F:\OS2\CHKDSK.COM D: /C
in config.sys. These will run at full speed. These can be RUN commands,
but then there needs to be something that will ensure the chkdsks have
finished before allowing applications to access the volumes that chkdsk is
processing.
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
--------------------------------------------------------------------------------------------
Marcel Müller
Steven Levine wrote:
> Lateautocheck is useful for volumes that will not to accessed by anything
> that starts automatically. For volumes that need to be autochecked
> earlier, I use
>
> CALL=F:\OS2\CHKDSK.COM D: /C
>
> in config.sys. These will run at full speed.
OK, the only drawback is, that they will not run in parallel. No
problem, when only one physical disk is in the system.
> These can be RUN commands,
> but then there needs to be something that will ensure the chkdsks have
> finished before allowing applications to access the volumes that chkdsk is
> processing.
I made the experience that the PMSHELL really dislikes chkdsk /C at
startup. From time to time this gives really bad crashes. I think the
shell cannot deal with clean drives that suddenly get locked (for a
short time) at startup. If the drive is unreadable from the first time
nothing happens. But clean drives are hopefully much more common.
This is the reason why lateautocheck avoids CHKDSK /C.
Maybe it is possible to RUN the chkdsk /C commands and call another
program that waits for them to complete later.
Furthermore one should avoid to check two volumes on the same physical
disk at once. This will really degrade the performance because of the
may long seek operations.
Marcel
tho...@antispam.ham
>>> What version of the JFS driver and utilities you are using?
>> Build Level Display Facility Version 6.12.675 Sep 25 2001
>> (C) Copyright IBM Corporation 1993-2001
>> Signature: @#IBM:14.105#@ IBM OS2 JFS retail bld
>> Vendor: IBM
>> Revision: 14.105
>> File Version: 14.105
>> Description: IBM OS2 JFS retail bld
>>
>> 05-01-01 6.32 6.417 0 ---- CHKDSK32.EXE
>>> Are you using bootable JFS?
>> No.
> All JFS files including the ujfs.dll are from Jan. 2006? That is the
> latest build from IBM.
06-01-25 14.50 44.344 61 ---- CACHEJFS.EXE
06-01-25 15.03 87.317 61 ---- CHKLGJFS.EXE
06-01-25 14.48 190.325 54 ---- JFS.IFS
06-01-25 14.48 12.619 0 ---- JFS.MSG
06-01-25 15.03 6.495 0 ---- JFSCHK32.EXE
06-01-25 14.48 9.515 0 ---- JFSH.MSG
06-01-25 15.03 251.285 54 ---- UJFS.DLL
tho...@antispam.ham
> Have you tried a CD boot and running chkdsk from there?
No; not sure how it would make a difference in this case.
tho...@antispam.ham
> For volumes that need to be autochecked earlier, I use
>
> CALL=3DF:\OS2\CHKDSK.COM D: /C
Hmm, out of curiosity, I tried CHKDSK /C and got the following:
] [W:\]chkdsk s: /c
] The current hard disk drive is: S:
] The type of file system for the disk is JFS.
] The JFS file system program has been started.
] CHKDSK Block size in bytes: 4096
] CHKDSK File system size in blocks: 29302552
] JFS0138: CHKDSK Checking a mounted file system does not produce dependable
] results.
]
] CHKDSK File system is clean.
] |........
] [W:\]dir s:
]
] SYS0627: Drive %1 was improperly stopped. From the OS/2 command
] prompt, run CHKDSK with the /F parameter on the specified drive.
So, the /C option by itself runs CHKDSK in such a way that it thinks
the dirty bit isn't set, but it obviously still is.
Steven Levine
at 07:30 PM, Marcel Müller <news.5...@spamgourmet.com> said:
Hi Marcel,
>> CALL=F:\OS2\CHKDSK.COM D: /C
>> in config.sys. These will run at full speed.
>OK, the only drawback is, that they will not run in parallel. No
>problem, when only one physical disk is in the system.
As I mentioned, they can run parallel if you use a RUN command. I just
didn't see the need to implement the plumbing to support it.
As with your lateautocheck, something needs to be done to prevent access
to the drive before it is ready to use or there will be spurious issues.
>I made the experience that the PMSHELL really dislikes chkdsk /C at
>startup. From time to time this gives really bad crashes.
I can believe this, although I've never seen it myself. The WPS does not
always properly handle drives that become available unexpectedly. I've
seen this with network drives that become detached.
In my setup, the chkdsks are completed before pmshell runs.
>Furthermore one should avoid to check two volumes on the same physical
>disk at once. This will really degrade the performance because of the
>may long seek operations.
Agreed.
Steven Levine
at 08:45 PM, tho...@antispam.ham said:
Hi,
>Hmm, out of curiosity, I tried CHKDSK /C and got the following:
>] [W:\]chkdsk s: /c
>] The current hard disk drive is: S:
>] The type of file system for the disk is JFS.
>] The JFS file system program has been started.
>] CHKDSK Block size in bytes: 4096
>] CHKDSK File system size in blocks: 29302552
>] JFS0138: CHKDSK Checking a mounted file system does not produce dependable
>] results.
>] CHKDSK File system is clean.
Note the warning. It means what it says. Don't depend on the messages
that follow.
>] |........
>] [W:\]dir s:
>]
>] SYS0627: Drive %1 was improperly stopped. From the OS/2 command
>] prompt, run CHKDSK with the /F parameter on the specified drive.
What happens if you follow the above recommendation? Since the drive is
mounted, I would expect chkdsk to refuse to honor the /F request.
>So, the /C option by itself runs CHKDSK in such a way that it thinks the
>dirty bit isn't set, but it obviously still is.
No it doesn't.
Regards,
tho...@antispam.ham
>> ] SYS0627: Drive %1 was improperly stopped. From the OS/2 command
>> ] prompt, run CHKDSK with the /F parameter on the specified drive.
> What happens if you follow the above recommendation? Since the drive is
> mounted, I would expect chkdsk to refuse to honor the /F request.
Apparently it isn't mounted. CHKDSK /F produces the same output as
during the boot process, namely the unrecoverable error reading M
from s:.
By the way, I googled the phrase and got some hits. There is the
suggestion that M refers to metadata. No suggestion as to why that
word isn't spelled out. Programmers seem to like cryptic error
messages.
ivan
My experience of the type of response you have means you a snowballs
hope in hell of getting anything from the drive - you will need to
format and restore from backup.
--
tho...@antispam.ham
> I hope you have a good backup.
I have a full backup from March. To the best of my recollection,
only a half dozen files were changed since March (the drive is
mainly used for archiving audio files), and most of those are
output files that can be recreated by running my audio editing
software again. The one or two input editing script may represent
lost work, but nothing major.
> My experience of the type of response you have means you a snowballs
> hope in hell of getting anything from the drive - you will need to
> format and restore from backup.
We'll see. I'm just wondering if the drive is going bad
mechanically, meaning that it's time to replace it, or whether
the problems were all caused by software doing something Bad,
in which case a reformat and restore may extend the useful
lifetime of the drive.
Mentore
I did pass through the same situation.
The solution was to recover all files from the "lost" volume onto
another volume and then destroy/recreate the broken media, using DFSee
and MiniLVM.
Using DFSee you can work on the broken volume, and search for all
files (or simply normal files): do a verbose search and not a quickFI,
you could lose all paths/names and it would be a PITA to rename each
and every ino-* file DFSee writes.
After creating the complete file list, just recover all files on a
separate directory in another volume (DFSee will warn you to use a
different disk/partition). Done that, simply use DFSee or MiniLVM to
recreate the damaged volume.
You might find some (or many, like my case) files named ino-
<<something>>. Those are broken inodes, sometimes they might contain
useful data, in my case I browsed through them and find every file
useless.
Have luck,
Mentore
Doug Bissett
Try it. There is definitely something different about the way that
CHKDSK runs, on JFS, when the system is booted from an alternate boot
source.
--
From the eComStation 2.0 RC6a of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
tho...@antispam.ham
>> ] JFS0138: CHKDSK Checking a mounted file system does not produce dependable
>> ] results.
>> ] CHKDSK File system is clean.
> Note the warning. It means what it says. Don't depend on the messages
> that follow.
Why is it that running CHKDSK without /F produces the warning, but running
CHKDSK with /F does not? The file system would appear to be mounted in both
cases. Or does CHKDSK know how to dismount a file system? If so, why
doesn't it do so regardless of whether the /F is present or not?
Marcel Müller
> Steven Levine writes:
>
>>> ] JFS0138: CHKDSK Checking a mounted file system does not produce dependable
>>> ] results.
>>> ] CHKDSK File system is clean.
>
>> Note the warning. It means what it says. Don't depend on the messages
>> that follow.
>
> Why is it that running CHKDSK without /F produces the warning, but running
> CHKDSK with /F does not? The file system would appear to be mounted in both
> cases. Or does CHKDSK know how to dismount a file system?
Exactly.
> If so, why
> doesn't it do so regardless of whether the /F is present or not?
No idea. Haven't tested that. As far as I remember HPFS operates this
way. Maybe the question is what happens if the drive could not be locked
because of open handles.
Marcel
Hendrik Schmieder
>
> I needed to reboot to restore operation of my audio, but during the
> reboot process, I received the following output:
>
> ] The current hard disk drive is: S:
> ] The type of file system for the disk is JFS.
> ] The JFS file system program has been started.
> ] CHKDSK Block size in bytes: 4096
> ] CHKDSK File system size in blocks: 29302552
> ] CHKDSK *Phase 0 - Replay Journal Log
> ] CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
> ] JFS0148: CHKDSK Unrecoverable error reading M from s:. CHKDSK CANNOT
> ] CONTINUE.
> ]
> ] JFS0148: CHKDSK Unrecoverable error reading M from s:. CHKDSK CANNOT
> ] CONTINUE.
> ]
> ] CONTINUE.
>
> The drive was working fine before the reboot. Now I can't access
> anything on the drive.
>
> What is "M"? Is that supposed to be the name of a file, a directory,
> or some data structure internal to JFS? I don't recall having any
> file or directory named "M".
>
> Is the only solution a reformat and restore from backup?
I once had the same.
In my case the drive was beginning to die.
Hendrik
Hendrik Schmieder
Do you have a maintenance partition.
If yes, boot this partition and try then a chkdesk /f.
If this doesn't work try it with /F:3
Hendrik