Hi,
this is a FYI bugreport. I acknowledge it doesn't contain useful
information for debugging, but in case there have already been related
reports, it may still be useful:
I recently had a mount failure for a jfs file system at boot-up, mount
complained about bad options or superblock, but no messages were stuffed
in dmesg.
Running fsck.jfs /dev/hda6 without further argument fixed this problem,
after fsck.jfs, I could mount the file system normally.
(fsck.jfs version 1.1.1, 17-Dec-2002)
Vanilla 2.4.26 kernel on SuSE Linux 8.2.
I haven't found any useful logs and didn't bother to dump the broken
file system image to tape or something because it struck a production
machine that needed to be brought back up quickly.
It is exported via NFS v2 and NFS v3 to Linux/x86 and Solaris 8/sparc64
clients.
The problematic file system was on an IBM IC35L060AVV207-0 drive that
was running with write cache switched off, it is an Athlon-XP 1700+
machine with 512 MB RAM and a VIA KT333 chip set that has been solid for
a long time.
The reboot that showed the mount error had been triggered by watchdog
that wasn't too happy that syslogd wasn't writing to /var/log/messages
(which was 2 GB sized after a looping process filled the disk)
Thanks for your attention,
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
On Tue, 08 Jun 2004, Matthias Andree wrote:
> I recently had a mount failure for a jfs file system at boot-up, mount
> complained about bad options or superblock, but no messages were stuffed
> in dmesg.
>
> Running fsck.jfs /dev/hda6 without further argument fixed this problem,
> after fsck.jfs, I could mount the file system normally.
> (fsck.jfs version 1.1.1, 17-Dec-2002)
Further info, it turned out that the fsck column for the respective file
system was 0. It has now been fixed to 2.
Question: is the JFS kernel driver supposed to mount a dirty file system
(replaying journal or whatever) without user space help - for instance,
if it's used as root file system?
On Tue, 2004-06-08 at 15:14, Matthias Andree wrote:
> Further info, it turned out that the fsck column for the respective file
> system was 0. It has now been fixed to 2.
>
> Question: is the JFS kernel driver supposed to mount a dirty file system
> (replaying journal or whatever) without user space help - for instance,
> if it's used as root file system?
No, all of the code to replay the journal is in user space. JFS does
allow a read-only mount when the superblock is dirty. This allows
fsck.jfs to replay the journal while the root is mounted read-only. /
can then be remounted rw after fsck runs.
--
David Kleikamp
IBM Linux Technology Center
On Tue, 08 Jun 2004, Dave Kleikamp wrote:
> No, all of the code to replay the journal is in user space. JFS does
> allow a read-only mount when the superblock is dirty. This allows
> fsck.jfs to replay the journal while the root is mounted read-only. /
> can then be remounted rw after fsck runs.
So was the mount was refused because a) the read-only
option was missing while b) the file system needed a journal replay?
Interesting difference. XFS insists on replaying the log in kernel space
(user space can only zero the log), ext3 and reiserfs can replay the log
in kernel or user space whichever touches first...
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
On Wed, Jun 09, 2004 at 12:35:28AM +0200, Matthias Andree wrote:
> On Tue, 08 Jun 2004, Dave Kleikamp wrote:
>
> > No, all of the code to replay the journal is in user space. JFS does
> > allow a read-only mount when the superblock is dirty. This allows
> > fsck.jfs to replay the journal while the root is mounted read-only. /
> > can then be remounted rw after fsck runs.
>
> So was the mount was refused because a) the read-only
> option was missing while b) the file system needed a journal replay?
>
> Interesting difference. XFS insists on replaying the log in kernel space
> (user space can only zero the log),
FWIW, all of the log replay code is there in userspace, so it
should just be a "simple matter of programming" to implement
this for XFS (noone has ever done so though, and its never
really been a priority for us).
cheers.
--
Nathan