Partition can't be mounted at boot but can be mounted by....

[pingtoo]

Bluey_the_dog,

Now it become the question on why dn_numag is 128.

I suspect it is the partition size.

the numag stand for number of allocation groups.

This may be a limitation of the jfsutils code. but unfortunately it is no longer being maintained. so unless you want to dig in the source code and patch your self, you may be out of luck.

may be you can try to resize the partition to say 500GB (or bit less) and try jfs_debugfs to see if it still report the dn_numag = 128.

[Bluey_the_dog]

Pingtoo,
To clarify, that statement came from the first two "tests", the kernels that worked. The partition would mount to /home upon boot so to test if the partition would also mount manually, "mount /dev/.......", I would just try and mount it to some other point, actually /mnt/ddd. I just did the same thing for all of the tests, for the second two, the ones that failed, I just did the same thing, try and mount to /mnt/ddd. Nothing special, no tasks taking a hold of things etc.

The thing that confuses me is that I am currently sitting at a machine that is running a standard gentoo-sources, 6.2.1 and as time has passed, plenty of previous kernels, and jfs has JUST WORKED. Why did someone decide that they wanted to come into the code and play merry hell with a big stick. They obviously didn't test the code as a partition of 531.5G is nothing out of the ordinary these days. Probably some deadhead trying to justify his/her existence and in doing so has caused, at least to me, a lot of lost time. Did the person who did this change work for RedHat by some chance?

Andrew

[Hu]

[Bluey_the_dog]

Hu,
Are you Hu or Pingtoo? It is 9am in Perth and I haven't been to bed yet and I'm getting confused as to who is who.

I don't want to get into a flame war but I am a Civil Engineer and have written code that is used in the analysis & design of multi story building, bridges, wharves etc, stuff that we test, test and test again before we release, we don't write the code then release "in good faith". To do so could cause the deaths of many people so hopefully you can understand my irritation at reading things such as "...and none of them kernel developers - who have recently created JFS filesystems."

By the way, no, I had not read the commit you linked to. The very few times I have looked at kernel code, I come away bewildered as I have no idea as to the context & conventions used in the code.

So what do I do now? Dump JFS?

Regards,
Andrew

[Hu]

Hu is Hu, and Hu is on first. Pingtoo is Pingtoo, and is on second.

If you are tired enough to mix up who is answering Hu, then I suggest you log off and get some sleep. At that level of exhaustion, it is dangerously easy to make system-killing mistakes while engaging in routine administration.

I cannot comment on whether you should dump JFS, though the references in this thread to its deprecation status would make me concerned about using it. As I see it, your options are:

• Dump JFS.
• Nicely report to the kernel maintainers that recent kernels fail to mount your JFS system. Be prepared to share enough information to convince them. A succinct reproducible test case would be very helpful here.
• Locally revert the bad commit in your kernels going forward.
• Stop upgrading your kernel.

[pingtoo]

[Hu]

A subsequent commit relaxed this check. See jfs: Fix sanity check in dbMount for mainline. It was also backported into active stable series.

commit ce781be80bd246d52d74bd9e667385f1c7104cfd v6.11.6
commit f475d8a0cca76da393c361932f5fd26cda75236b v6.6.59
commit d52ac941fe7de3e96acaf3cc6b6d6f41cf9356d4 v6.1.115
commit cdf3ab1cf811ce166dfcd83354a411caa8977c70 v5.15.170

I see no sign it is in v6.10.x, and since that is now end-of-life upstream, I do not anticipate a backport to that series.

[pingtoo]