Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 05 May 2013 11:24:30 +0100
From:      Matthew Seaman <>
Subject:   Re: pwd.db/spwd.db file corupption when having unsafe system poweroff
Message-ID:  <>
In-Reply-To: <>
References:  <> <kkkda5$vm9$> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 05/05/2013 07:12, takCoder wrote:
>> > Furthermore, file system corruption due to an abrupt
>> > cut of power should be avoided. Whenever the system comes
>> > up in a non-clean state, fsck should be run first, _then_
>> > the boot process should continue. Still it's possible that
>> > this process leaves truncated files behind (e. g. the
>> > binary database files with a length of zero, which implies
>> > they will have to be rebuilt by pwd_mkdb).

> i added fsck_background=3Dno to rc.conf but i still see the error.. and=
> don't see any differance in system startup output! how should i know it=
> working??

You won't see any difference if things are all running smoothly --
that's because fsck is only required in the case of an unclean shutdown.
and that simply won't happen at all for an ordinary system reboot.

The main difference you'ld see with fsck_background=3Dno is that the
system will take longer to come on-line after a crash.  Depending on the
size of your filesystems and how much you have stored in them, it can be
very much longer: I've seen filesystems take hours to run a fsck.

That's why background fsck exists -- it's better in many cases for a
machine to be up and running and productive again quickly, even at the
slight risk of problems due to filesystem corruption during the crash.
With techniques like soft updates, which ensures file system meta-data
consistency, the risks of such corruption are very much lower than
without.  Journalling effectively extends the same guarantee to data as
well as to meta-data.  And then there's the ZFS approach, where the
copy-on-write semantics means that what is on disk is always coherent,
although an unclean shutdown can lose the last few uncommitted changes.

All in all, however you manage your disks the problem remains that in an
unclean shutdown, filesystem changes in progress at the time of the
crash will be lost.  The best thing you can do to preserve your data is
to minimize the chances of unclean shutdown.  Which could be as
expensive as installing UPSes everywhere, or as cheap as re-educating
your users that pulling the plug or pressing and holding the power
button is a "bad thing(tm)."[*]



[*] Some might suggest that this re-education is best achieved by a form
of Pavlovian conditioning using severe negative reinforcement involving
blunt force trauma.

Dr Matthew J Seaman MA, D.Phil.

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Thunderbird -



Want to link to this message? Use this URL: <>