JFS is flakey

[John Moser]

JFS seems very, very, very very very flakey. I installed with a JFS root, it only seems to replay journal by fsck (not at mount time). Further, after 2 or 3 hard system locks (unstable AMD64 kernel 2.6.15-15 on dapper, it freezes quite a lot) the file system was corrupted to the point that the dpkg database got destroyed in the last system failure; the ubuntu Human GDM theme got corrupted somehow; and GNOME did not want to load properly.

I am fairly convinced that the JFS driver is not well implemented, or JFS is just not well designed. In either case JFS should definitely NOT be used at this point.

I have no idea how to deal with this bug. It basically ammounts to, "This FS are sux, it breaks far too much and should not be used." The problem is, across an AMD64, qemu, and x86 install (yes only 3 tries) that occured years apart, it appears to be true; JFS is very, very fragile.

[Matt Zimmerman (mdz)]

Ubuntu doesn't use JFS by default

[floid (jkanowitz)]

With 2.6.15-20 i386 (32-bit), Dapper Flight 6, JFS is giving equal headaches.

The biggest showstopper appears to be that fsck.jfs does not always detect a dirty filesystem, leading to a 'successful' journal replay in ignorance of corrupt entries. This is being a particular bear with X.org/gdm-related entries in /tmp, given my machine's tendency to jam itself in odd ways immediately after opening files there. (See #39333)

Doing a forced check actually cleans things up.

A concomitant issue is the boot process's handling of the case where fsck.jfs doesn't do its job and so a JFS root partition comes up read-only. Lots of things fail there, obviously, but some truly weird things happen (bash with no job control coming up 'over' a text-gui gdm complaint dialog, other consoles and instances of login seeming to initialize or not at random) ...

IMHO, the boot scripts should check that all requisite locations are writable (/tmp, /var/log, where else?) and bomb straight to a shell -- with instructions for continuing after a manual fsck -- if not.

[T-Bone (varenet)]

ia64 with IDE HD. Fresh Dapper Beta install, completely ruined after a few minutes (corrupted/deleted files everywhere, dpkg db corrupted, gnome unable to start, etc...).

Had to reinstall the box.

Ubuntu may not use JFS by default but the Ubuntu kernel provides support for it, so it might be a good idea to disable it if it's so buggy and nobody cares?

HTH

T-Bone

[John Moser (nigelenki)]

I was thinking warning in the installer. "You have chose to format the below partitions as JFS. JFS IS VERY UNSTABLE. ARE YOU SURE YOU WANT TO DO THIS?"

[Carthik Sharma (carthik)]

Confirmed by other reporters. Since there is a warning message as someone pointed out, is this really a bug?

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Ali Sabil (asabil)]

The issue is still here with intrepid, and it even got worse than with Hardy.

[Graziano (graziano-giuliani-gmail)]

I am using jfs as my root filesystem from feisty (now on jaunty), and I have not got much issues with the filesystem itself. I DO think this IS NOT an issue with kernel or jfs driver. This seems much related to userspace jfsutils AND/OR initscripts.

First: jfs mount option are very limited, and practically are always defaults in fstab. I have experience once of a system where they have put noatime options which is not allowed by jfs, resulting in a mount failure each reboot.
Second: on Jaunty (not experienced on Feisty, Gutsy, Hardy or Intrepid) the jfs filesystem at boot needs ALWAYS to replay log, so what I think is that umount does not flush journal to disk. jfs MUST be checked for me at boot. On my laptop I had to disable check for battery power and enable fsck by default regardless of battery.

[Benjamin Mako Hill (mako)]

I've been using JFS on multiple systems on every Ubuntu release (i.e., since pre-Warty).

I can echo what Graziano has said. I've got nothing but good things to say about the FS. I've got a lot of criticism with the support for tools. Everything from mount to sysvinit has little nits that, especially for the uninitiated, can make dealing with JFS a PITA.