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

pingtoo · Posted: Fri Oct 11, 2024 11:29 pm Post subject:

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 · Posted: Sat Oct 12, 2024 12:07 am Post subject:

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 · Administrator Joined: 06 Mar 2007 Posts: 22495

Bluey_the_dog · Posted: Sat Oct 12, 2024 1:24 am Post subject:

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 · Administrator Joined: 06 Mar 2007 Posts: 22495

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.