Date: Mon, 1 Aug 2005 10:58:08 +0200 From: Marc Olzheim <marcolz@stack.nl> To: freebsd-stable@FreeBSD.org Subject: Re: background fsck, softupdates & inconsistent state on disk Message-ID: <20050801085808.GA28473@stack.nl> In-Reply-To: <20050721094533.GE52120@stack.nl> References: <20050721094533.GE52120@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 11:45:33AM +0200, Marc Olzheim wrote: > Having enough opportunities to do crash recovery with kern/83375 open > and some of my services not yet moved back to FreeBSD 4, I noticed that > often it crashes just after (or perhaps during) mirroring of a directory > tree. The mirroring involves creating a directory with in it 80 > subdirectories in it. >=20 > Now when the machine panics on a 'screen' again, background fsck fails > to properly check the filesystem and reports so in /var/log/messages. > What I see on that partition is the main directory that should have > contained the 80 subdirs, but now it has a link count of 0 and so > doesn't even contain a . or .. , let alone the 80 directories that > should have been there. >=20 > The only thing a manual fsck can do after that is unlink the > unreferenced inodes and clear up the mess... Ok, this time it's worse; Trying to startup single user, gives: WARNING: / was not properly dismounted start_init: trying /sbin/init WARNING: R/W mount of / denied. Filesystem is not clean - run fsck WARNING: R/W mount of / denied. Filesystem is not clean - run fsck WARNING: R/W mount of / denied. Filesystem is not clean - run fsck =2E.. And it won't snap out of it... Luckily we start a 'remote control daemon' before fsck is started, so I managed to run 'fsck /' manually: rcntlc> shell sh -i Press CTRL-A to escape from this mode sh: can't access tty; job control turned off # fsck / ** /dev/da0s1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2174 files, 29734 used, 97105 free (225 frags, 12110 blocks, 0.2% fragmenta= tion) ***** FILE SYSTEM MARKED CLEAN ***** # So I'm not sure what the problem was... > Shouldn't this be impossible without power loss ? Or is it inherent to > SMP that the machine can crash on a process on CPU #0 while CPU #1 is > updating disk structures ? Marc --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7eQgezjnobFOgrERAsg0AJ9yoh9HqsbKKIjvdqYgfzMD4pE9FgCdGajF mzKiUs9D2Tbi6AIoZOIV4WE= =XSTG -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050801085808.GA28473>