Author Topic: Problems with JFS  (Read 2081 times)

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 26
  • Posts: 529
    • View Profile
Problems with JFS
« on: May 06, 2016, 07:42:19 pm »
Hi All

This started as a side discussion to http://www.os2world.com/forum/index.php?topic=1026

A brief recap: After installing JFS-1.09.06 from Arca Noae my system can "lose" a volume at boot. The first time this happened I only noticed after the Desktop had loaded and I opened the Drives folder to use the "missing" drive.

Running LVM it looked as the the volume had not yet been added to the drives available list as it was not in column with the other drives but off to the left - as though the volume had only just been created.

I made absolutely NO changes in LVM but used the Save and Exit option when quitting.

The "missing" drive appeared in the Drives folder.

This is something that happened frequently while I had this release of JFS installed - but not with previous builds ie 1.09.05 and earlier.

It happens on 2 AMD based desktop systems and 2 Intel based laptops.

I am assured there is nothing wrong with the driver... Strange that it happens across a range of hardware though.

A suggestion was put forward that it could be some sort of shutdown problem; possibly the disk cache is not being fully flushed before the system powers off or reboots.

Yet again, not a problem prior to JFS-1.09.06

I was encouraged to install the latest XWP beta as that has some updates which may help and retest the JFS-1.09.06 driver. The XWP beta does not make any difference - does not seem to be anything wrong with the XWP beta, works smoothly and is here if interested  ftp://ftp.netlabs.org/pub/wlan/xwp-3.unofficial-1-0-10.zip

What can I be doing wrong on my range of hardware?

All systems have eCS2.2beta2 installed; the desktops also have eCS2.1+ with updates from eCS2.2beta2 plus Arca Noae.

Prior to installing JFS-1.09.06 I run chkdsk against all drives and check that they report "clean".

I then install the JFS package and reboot.

I had not performed this next step before yesterday when I reinstalled JFS-1.09.06 for testing with the XWP beta: When the Desktop has loaded and the system has "settled down" I ran chkdsk aginst all the JFS formatted volumes that were *known* to be clean immediately before the JFS package was installed.

Several of the volumes reported this problem:-

CHKDSK  Incorrect data detected in disk allocation structures.
CHKDSK  Incorrect data detected in disk allocation control structures.
.
.
.
CHKDSK  File system is dirty.
CHKDSK  File system is dirty but is marked clean.  In its present state, the
results of accessing i: (except by this utility) are undefined.


Strange... why should these drives be "dirty but is marked clean"? I guess that is where the shutdown possibility occurs - and could be the cause of the "lost" volume at boot.

I ran chkdsk against the drives with problems and found that chkdsk did not want to play with 1 of my drives something like "Cannot open for write access. Performing readonly check" or something very similar. What???  That sounds serious but, usually, is not if JFS-1.09.06 is installed - it means that it needs a different JFS package that works.

I had installed the JFS-1.09.06 package to my eCS2.1+ system; on the same system I have a bootableJFS eCS2.2beta2 installation and another eCS2.2beta installation on a HPFS formatted volume; the HPFS installation still has the earlier JFS-1.09.05 package installed and has this line in the config.sys file:-

IFS=M:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*


Yes, the HPFS install exists mainly to perform a full forced chkdsk during boot when JFS-1.09.06 stuffs up.
(A side note here: For those who do not know the above config.sys line does not work with JFS-1.09.06 as support for the "+" option has been dropped. My suggestion: Do *not* use JFS-1.09.06 on a "headless" server.)

The volume that JFS-1.09.06 could not chkdsk was processed by chkdsk/JFS-1.09.05 without problems, applications installed on that volume worked fine.

After a reboot back to the eCS2.1+ install chkdsk again reported several volumes as "dirty but is marked clean" - yet again, possibly a shutdown problem... ???

This time chkdsk was able to process all volumes without any problems.

When I next performed a chkdsk - probably around 3 hours later just before shutdown for the night - guess what I discovered? Yes, several volumes "dirty but is marked clean".

The system had not been shutdown between the earlier chkdsk that "fixed"? whatever problems and this chkdsk. That seems to rule out shutdown as a problem and leave JFS-1.09.06 as the culprit - unless anyone can come up with any other possibilities?

I guess any of the applications I used or the data I saved may have caused the problem - but, the problem does not seem to exist with JFS-1.09.05...


Any thoughts?


Pete


















Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 38
  • Posts: 925
    • View Profile
Re: Problems with JFS
« Reply #1 on: May 06, 2016, 10:10:43 pm »
This is a very strange problem. I will add my thoughts, and comments.

Quote
After installing JFS-1.09.06 from Arca Noae my system can "lose" a volume at boot. The first time this happened I only noticed after the Desktop had loaded and I opened the Drives folder to use the "missing" drive.

I have never seen anything like that on my real hardware. I do, however, see something similar in one of my VBox systems (win7 host on my Lenovo T510, multiple versions of VBox). Every once in a while, it fails to attach one of the drives, for no apparent reason. FWIW, this was also happening with JFS 1.09.05.

The virtual system consists of:
2G boot drive C: eCS 2.1, AHCI attached bootable JFS.
2G boot drive M: eCS 2.2b2, AHCI attached bootable JFS.
15G data/programs W: AHCI attached advanced JFS.

Each is an individual *.VDI file. The first (C:) has AirBoot installed.

When the problem happens, the W: drive is not attached, and a reboot always works. It seems to be slightly different from what you describe, but it could be related, somehow.

Quote
I am assured there is nothing wrong with the driver...

I use JFS on a number of different systems, including VBox machines. Other than the above anomaly (which looks more like it could be a flaw in VBox), I have seen no problems. I did see one case of the known problem with JFS 1.09.05, which was pretty nasty. Fortunately, it happened on a USB attached backup drive, and it was easily recovered (full partition recreation, and format, then do the backups again). You won't see me going back to anything earlier than JFS 1.09.06.

Quote
The XWP beta does not make any difference - does not seem to be anything wrong with the XWP beta

The XWP beta seems to work better than any of the "official" releases, but I am pretty sure that there is still a shutdown problem, if you don't use the setting to delay shutdown. I haven't seen your problem, but I did have some INI file corruption after a couple of shutdowns without the delay. I turned the delay back on, and I haven't had any problems since then (but I have only power cycled about 3 times). I do notice that the latest ACPI actually powers off my machine on a reboot, where earlier versions (and win 7 and 10) don't do that. It doesn't seem to vause any problems though.

Quote
What can I be doing wrong on my range of hardware?

It is probably a startup conflict of some sort. How do you sort your CONFIG.SYS? I always use my LCSS (Logical ConfigSys Sort) package (HOBBES), and on faster machines, I find that I need to introduce one, or two, 2 second delays at strategic spots, to avoid other problems. I use http://www.tavi.co.uk/os2pages/utils/delay.zip. One right after the IFS entries, and one at the end (LCSS will respect the positions, when it can).

Quote
Strange... why should these drives be "dirty but is marked clean"?

Good question. I don't ever remember seeing that message, but others seem to have problems, for some reason.

Quote
My suggestion: Do *not* use JFS-1.09.06 on a "headless" server.

Again, this doesn't really make sense. I don't use my eCS based NAS box headless, but the screen is normally turned off. I find no reason to want to run CHKDSK (although I do, sometimes, just because...). Over the last few years, I don't remember any case where CHKDSK ever found anything bad on any of my JFS drives, even when I need to use the reset button. That could be coincidence, but JFS tends to keep itself clean.

Quote
unless anyone can come up with any other possibilities?

You wouldn't have an old version of CHKDSK, or UJFS.DLL, hiding somewhere, would you?

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 630
    • View Profile
Re: Problems with JFS
« Reply #2 on: May 06, 2016, 10:22:23 pm »
Hi Pete,

All I can say is, stick with what works.

I do agree with you that there appears to be a problem with JFS-1.09.06 that others have not encountered for some reason, different setups, disk configuration and partition sizes.

What you are seeing would indicate a lack of testing on a wide diverse set of machines and configurations.

Here at work we have a healthy respect for the problems that JFS formatted disks can have, we 'lost' just on 450GB of data that was on a JFS volume when something went wrong with the data structures and since there is no reliable way of recovering any of the data we had to reformat that partition and restore from backup.  Since then all our JFS partitions are backed up twice a day with incremental backups and there is NO way we will use a bootable JFS volume.  All bootable partitiond on the workstations are HPFS and on the servers HPFS386.

roberto

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 6
  • Posts: 295
    • View Profile
Re: Problems with JFS
« Reply #3 on: May 06, 2016, 11:49:49 pm »
Hello Pete

This is something that happened frequently while I had this release of JFS installed - but not with previous builds ie 1.09.05 and earlier.

It happens on 2 AMD based desktop systems and 2 Intel based laptops.

If you have that problem in 4 pcs, and others we do not have that problem. I would do the following:
I would remove one of the hard drives of one of the pcs , not to touch anything , and put another disc for testing.
I would not put any data at all in principle erase the disc, would create the volumes , similar to those that have disconnected.
Install the system from scratch , update it and try it first only with the system, then with any program , and finally with data.
With this proposal, I do not mean that the problem is on the hard , the data could be or could be some very personal settings yours. But I think with this you can locate the problem.

Saludos


John Poltorak

  • Full Member
  • ***
  • Thank You
  • -Given: 16
  • -Receive: 0
  • Posts: 232
    • View Profile
Re: Problems with JFS
« Reply #4 on: May 07, 2016, 05:36:35 am »
Pete,

Is there any chance of checking your disks for bad sectors? Not sure what you would use... maybe DFSee...

Could it be that the older JFS was unable to detect some errors whereas the new version is less forgiving and panics when there is a problem...

Just a thought...

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 38
  • Posts: 925
    • View Profile
Re: Problems with JFS
« Reply #5 on: May 07, 2016, 08:23:11 am »
Quote
Here at work we have a healthy respect for the problems that JFS formatted disks can have, we 'lost' just on 450GB of data that was on a JFS volume when something went wrong with the data structures and since there is no reliable way of recovering any of the data we had to reformat that partition and restore from backup.  Since then all our JFS partitions are backed up twice a day with incremental backups and there is NO way we will use a bootable JFS volume.  All bootable partitiond on the workstations are HPFS and on the servers HPFS386.

Other than the known problem in JFS 1.09.05 (which is very rare, and CHKDSK was of no help, at all), which was fixed in 1.09.06, I have had no problems with JFS. I have simply quit using anything except JFS and FAT32 (for windows compatibility). JFS boot partitions are bullet proof. Far more reliable than HPFS ever was (I have never used HPFS386). Getting rid of HPFS also freed up a good chunk of low shared memory space, which solved a couple of other problems. Bootable JFS is also noticeably faster than HPFS. FWIW, your problem sounds a lot like what was fixed in JFS 1.09.06.

One of the problems with trying to recover data from a damaged disk (all platforms, all formats, even with RAID) is that there is now so much data, that it is difficult to manage it all. My brother accidentally deleted a couple of files on a 1 TB partition, with about 400 GB of data on it (it was NTFS in windows, on USB 3.0). We tried DFSEE, and it took 70 hours to scan the disk, but it appeared that the files were overwritten almost immediately, so they weren't found. Fortunately, they weren't critical.

Quote
Is there any chance of checking your disks for bad sectors? Not sure what you would use... maybe DFSee...

It is highly unlikely that multiple systems would have bad sectors (especially with modern disk drives). It is more likely that his setup has some trap in it that gets duplicated across his systems. That is why I suggested that a startup conflict is likely what is causing the problem. JFS 1.09.06 starts up a lot faster than the older versions, and something may not be quite ready when other things get started. Fixing startup conflicts is more of an art than a science, and they can cause problems at boot time, while you are running, and even at shutdown. It all depends on what happens, and when. The usual fix is to introduce some extra delays, or reorder the startup sequence. I had one VM that would hang every time the GUI started up. The "fix" was to reduce the processor to 50% until the rest of the system was installed (which added more things to CONFIG.SYS). After the install, I was able to put it back to 100%, and it has caused no further problems. Unfortunately, you can't do that with a real system (not easily anyway).

Andreas Schnellbacher

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 14
  • Posts: 233
    • View Profile
Re: Problems with JFS
« Reply #6 on: May 07, 2016, 04:09:07 pm »
Hi Pete, unfortunately there are no useful ideas so far, IMO. Good luck. It would help to see a report with that issue reproduced.

Dariusz Piatkowski

  • Sr. Member
  • ****
  • Thank You
  • -Given: 12
  • -Receive: 6
  • Posts: 268
    • View Profile
Re: Problems with JFS
« Reply #7 on: May 08, 2016, 02:24:31 am »
Pete,
Do you still have an active HPFS partition present while you boot off of the JFS?

I ask this because I previously experimented with JFS (older version though)...and since I ran HPFS386 (with fairly sizeable cache - 512MB) across all of my OS/2 drives I ran into some serious problems, JFS was completely unusable. This actually caused my bootable HPFS386 partition to get trashed...since then I have left JFS alone and have not got any further.

So....if you have an active HPFS partition, maybe you are seeing some kind of "in-stability" between the two filesystems along the lines I have exeprienced.

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 26
  • Posts: 529
    • View Profile
Re: Problems with JFS
« Reply #8 on: May 12, 2016, 03:19:10 pm »
Hi All

@Dariusz
HPFS386 is not involved at all. I think standard HPFS is expected to work fine with JFS but .... Maybe worth investigating.

@Andreas
Au contraire mon ami :-)
Doug has put forward a couple of ideas - and also the fact that he has seen something similar when booting eCS within a virtualbox. He also states that it happens with both 1.09.05 and 1.09.06 - and 1.09.06 was supposed to fix this problem. We also established that the problem is not fixed by the current XWP beta.

@ivan
It is several years, probably around 12, since I last had any serious problems with JFS - if I remember correctly on a boot after a successful shutdown with no problems while in use JFS did a chkdsk on my data drive and decided to throw away (I think chkdsk called it "release nodes") my Seamonkey Profiles. No problems since then until now.
However, moving boot drives back to HPFS is now under way on all systems here but there is no alternative to JFS for larger, >50GB, volumes so I am stuck with JFS for data drives. Guess I'll have to start daily backups in case...

@roberto
Both laptops had recent "clean" installs to disks that had had all existing volumes deleted and volumes of different sizes to those deleted were created. After updating JFS the "lost" volume problem started. You may have a point that the problem could be my eCS install selection or the settings in use - none of them should directly affect JFS working though unless the OS itself has a more serious underlying problem.

@Doug
No duplicate JFS/chkdsk files on the system except those in \os2\install.
I have investigated config.sys delays and sorting without any change in behaviour of JFS-1.09.06.
Interesting that you have seen something similar - and probably related - when booting eCS within a virtualbox. I guess I should point David at this discussion in the hope that he can formulate some ideas about this problem.

A "Headless" server does not have mouse, keyboard or monitor attached and is often found using space that you cannot use a desktop system in. The last thing you need is to have to drag the server into a big enough space, hunt out some hardware to attach and, in worst cases, play "hunt the Install CD". Far easier if the server has a crash to simply let the config.sys statement

  IFS=M:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*

sort out any problems that the crash may have caused the filesystem. Of course, you need JFS-1.09.05 or earlier to do that.


@All

I know that running chkdsk on a mounted drive does not produce dependable results but I suspect that if the result is "dirty but is marked clean" then the drive really does need a full chkdsk.

I was looking for a possible Shutdown problem but a drive that was cleaned by running chkdsk after the system had booted was "dirty but is marked clean" a couple of hours later without any obvious system glitches.  Maybe something screws up in use rather than at Shutdown or Bootup?

What other drivers are actually involved in reading/writing to disk? os2dasd.dmd, os2ahci.add, jfs.ifs - anything else?

I guess I could look at switching from AHCI to IDE to see if that makes any difference.


Thanks for thoughts to date.


Regards

Pete

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 12
  • Posts: 311
    • View Profile
Re: Problems with JFS
« Reply #9 on: May 12, 2016, 05:22:21 pm »
Quote
is not fixed by the current XWP beta
A few months ago I've increased the shutdown delay in XWP from I think 500ms to 700ms. On very rare conditions the graphic output of my X300 was not switched off before when shutting down although the rest of the system was switched off. I think this increase has fixed my problem. But as it was so rare and maybe dependent on the USB stack and used devices (which I've changed too in the meantime) I'm not sure if this change really helps.

If you like you can test this version or I can compile you a version with 1s delay. I guess you will not like to make much testing with your server but if yes, let me know.


roberto

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 6
  • Posts: 295
    • View Profile
Re: Problems with JFS
« Reply #10 on: May 12, 2016, 05:26:38 pm »

@roberto
Both laptops had recent "clean" installs to disks that had had all existing volumes deleted and volumes of different sizes to those deleted were created. After updating JFS the "lost" volume problem started.
Well, Why not erase all data volumes other than the boot? . And tests to boot. I understand that you do not have the x:\home\default\ folder on the boot . In this case I delete it too.
Then you can restore it.
This is to rule that the data is not the problem.

Saludos

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 38
  • Posts: 925
    • View Profile
Re: Problems with JFS
« Reply #11 on: May 12, 2016, 05:34:38 pm »
Quote
and 1.09.06 was supposed to fix this problem.

I don't know about THIS problem. It is supposed to fix a problem where the file system gets damaged beyond repair. Since that is very rare, all I can say is that it hasn't happened to me again.

Quote
We also established that the problem is not fixed by the current XWP beta.

That would be the shutdown problem where the final data never gets to the disk. We also don't know if that is what is causing your problem.

Quote
Interesting that you have seen something similar - and probably related - when booting eCS within a virtualbox. I guess I should point David at this discussion in the hope that he can formulate some ideas about this problem.

I am not sure that I would say "Probably" related. More like "possibly" related. I am more inclined to think that is a VBOX problem where it doesn't attach the drive on the first try. It never needs a CHKDSK when it does get attached. A normal warm reboot, gets it attached.

Quote
Far easier if the server has a crash to simply let the config.sys statement

  IFS=M:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*

sort out any problems that the crash may have caused the filesystem. Of course, you need JFS-1.09.05 or earlier to do that.

Personally, I have never, yet, seen any reason to even think about forcing a CHKDSK on reboot (real, or virtual, machines). The normal CHKDSK, if the disk is found dirty, rarely finds anything to fix, other than to mark it clean.

My "headless server" does have the devices attached, but they might as well not be there. I do have a problem with that machine where the BIOS, and the OS, don't agree on which disk is first, but LVM seems to look after that (but an Air Boot programed restart is confused). It is my eCS based NAS box. An old P4 with a SATA adapter card, and a 2 TB disk for storage (it was 1 TB until recently). Booting is done from an older 200 GB IDE drive.

Quote
If you like you can test this version or I can compile you a version with 1s delay. I guess you will not like to make much testing with your server but if yes, let me know.

I am pretty sure that 500 ms is not enough, and 4s is too much (but it seems to be safe). It is my opinion that a minimum of 1 second should be implemented, with an option of 2 seconds (for slow disks, in fast machines). One (or 4) extra second(s) to get it turned off will never be a problem, while having corrupted INI data, or having to wait for a CHKDSK on boot, can waste a LOT of time.

roberto

  • Sr. Member
  • ****
  • Thank You
  • -Given: 13
  • -Receive: 6
  • Posts: 295
    • View Profile
Re: Problems with JFS
« Reply #12 on: May 12, 2016, 07:19:41 pm »
You can do another test, and force a checkdisk turning off the computer(after install jfs 06),unplugging. and see if the system is able to repair the error during startup. This is similar to run this in your config.sys
IFS=M:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*

saludos

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 38
  • Posts: 925
    • View Profile
Re: Problems with JFS
« Reply #13 on: May 12, 2016, 07:49:54 pm »
You can do another test, and force a checkdisk turning off the computer(after install jfs 06),unplugging. and see if the system is able to repair the error during startup. This is similar to run this in your config.sys
IFS=M:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:+*

Actually, it is not similar. +* is supposed to run a full CHKDSK on all (JFS) drives (apparently disabled in JFS 1.09.06). Pulling the plug leaves the drives marked dirty (and may damage your machine, in some cases), and CHKDSK looks in the journal to see if anything needs to be checked. If the journal entry is clean, it doesn't do any more with that section of the disk. If all journal entries are clean (99% of the time, in my experience), it simply marks the drive as clean. Apparently, there are a few things that can sneak past that test, but they seem to be very rare.

IMO, it is much better to simply run a proper CHKDSK on every drive, from an alternate boot system, every once in a while (3 months, or when you suspect a problem) than to try to use the "+" parameter on the CONFIG.SYS line. I haven't actually seen it happen, but I suspect that a large disk (2 TB, mostly full) on a small memory system (512 meg), probably cannot run CHKDSK successfully, because (even with the driver) there isn't enough memory, and paging isn't available when it needs to be done. Doing it from an alternate boot system makes sure that the drive is not being used, and it should be able to use paging.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 87
  • Posts: 1096
    • View Profile
Re: Problems with JFS
« Reply #14 on: May 13, 2016, 04:24:29 am »
With older versions of JFS, I've had chkdsk run  out of resources a few times, IIRC, with a 8or16GB partition and a GB of memory except the last time, which was a newer one and running chkdsk once the system was up succeeded. Previously there was one time where even the Linux fsck couldn't finish, ended up mounting it read-only under Linux and copying everything off the partition. Another time the Linux fsck finished really quick successfully and another time I was saved by using the undocumented /d switch, chkdsk f: /d.
I've also seen the marked clean but dirty warning a few times. My guess is the journal didn't get finalized during shutdown but the drive was still marked clean.
The only thing I've lost was parts of my Thunderbird profile when the computer ran out of shared memory and trapped while downloading mail.
I now use a script to run chkdsk on my data partitions after the system is up, which also has the advantage of running 2 instances of chkdsk, one for each drive.