[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/40474: Kernel panic after remounting raid root with softdep
The following reply was made to PR kern/40474; it has been noted by GNATS.
From: Tero Kivinen <kivinen%iki.fi@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: kern/40474: Kernel panic after remounting raid root with
Date: Tue, 27 Jan 2009 15:25:00 +0200
David Holland writes:
> I'm pretty sure turning softdep on after mount is a known problem, and
> that there's an existing PR about it, but I can't find one. Anyway, I
> doubt it's got much to do with either vi or raid.
I remember doing it earlier. Usually quite soon after install, i.e.
noticed that fstab is missing softdeps and unpacking pkgsrc.tar.gz was
slow because of that, and then added softdeps to fstab and said mount
-u -o softdep / to get it effective immediately for the already
I noticed the problem now as I tried to do the same and the machine
paniced when I tried to edit fstab after remount...
> The immediate problem appears to be that it's allocating the same
> inode twice. I think this is probably happening either because of a
> general known problem with mount updates not flushing things properly
> (e.g. PR 30525)... or because softdep uses different rules for
> handling free object bitmaps from baseline ffs, and after the mode
> transition not all filesystem state is arranged the way softdep
It could be that it is actually crashing on file creation, so
allocating inode twice could be the rason (vi creates the recovery
> Did the fsck after the crash show any problems?
The first fsck removed lots of files, so many that I needed to rm -rf
/usr/src and cvs checkout it again to get it working again. I think I
had just before (or during, dont remember exactly) said cvs update on
the /usr/src, so most likely it several CVS/* files.
Later times when I tried it immediately after boot, fsck reported some
unreferenced files etc, but nothing special there.
> And, if you reboot again without having used softdep, boot to single
> user, and force running a fsck, does *that* show any problems? (In
> fact, it's probably a good idea to do such a fsck on general
> principles; fsck behaves differently if it thinks softdep was in
> use, so crashing in this fashion might have confused it.)
As the /etc/fstab was still configured without softdep all the fsck
runs were done without softdeps.
> If you have a test machine to crash on, the following information
> might be useful, maybe:
My test machine was my main machine I was updating to NetBSD-5.0beta
and as it is already done, I don't want to crash it anymore
(reconstructing 1.5 TB of raid takes a long time...).
> - If you sync after the remount, does the crash still occur?
> (I expect it will, but it would be interesting if it didn't.)
I think I tried that already, i.e. said:
# mount -u -o softdep /
# vi /etc/fstab
My normal reflex is to type sync few times at that kind of times, so
my guess was that I tried that too (but I am not sure, as I didn't
record my commands exactly).
> (None of this is worth crashing anything other than a test machine to
> find out, though.)
As I said my test machine is already back in use, so cannot do those
Main Index |
Thread Index |