Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Aug 2014 15:40:39 -0700
From:      David Benfell <benfell@parts-unknown.org>
To:        Polytropon <freebsd@edvax.de>
Cc:        Roland Smith <rsmith@xs4all.nl>, freebsd-questions@freebsd.org
Subject:   Re: operation not permitted on entropy file
Message-ID:  <20140810224038.GD24036@home.parts-unknown.org>
In-Reply-To: <20140810124433.da498898.freebsd@edvax.de>
References:  <20140810070239.GA80734@home.parts-unknown.org> <20140810103119.GA26958@slackbox.erewhon.home> <20140810124433.da498898.freebsd@edvax.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--YToU2i3Vx8H2dn7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 10, 2014 at 12:44:33PM +0200, Polytropon wrote:
> Allow me a small additional statement:
>=20
> On Sun, 10 Aug 2014 12:31:19 +0200, Roland Smith wrote:
> > If a filesystem isn't dismounted properly (e.g. because of a crash), you
> > should get a warning during the next boot. And the system would run a
> > filesystem check in "preen" mode (see fsck(8)). If it finds serious err=
ors
> > that cannot be repaired in preen mode, you should get an error message.
>=20
> The problem is: When you do _not_ have
>=20
> 	background_fsck=3D"NO"
>=20
> in /etc/rc.conf, all this happens in background, and soon you're
> in XDM and your X session, so you don't get the error message.
> Still the system continues booting and working "normally" for
> the price of "silent" file system corruption.

I was wondering about this.
>=20
> In my opinion, this setting should be the default. It's better
> to have a delay in the boot process, or a _stop_ of the boot
> process in case a severe file system damage has been detected.
> I also think it's more important to know about this fact than
> it is to quickly be guided into a "comfortable environment"
> that makes you believe everything is okay, while in fact it
> isn't.

Based on this experience, I agree. And I have now implemented the
above setting. I don't think crashes should be treated as normal,
especially when, as I do, you have a UPS providing backup power.
>=20
> > Trying to make a backup in this state will probably not work.
>=20
> Maybe files cannot be read, or are improperly read (and therefore
> wrongly represented in the backup). When I do backups, I usually
> make sure two things: 1st, the file system is _clean_, 2nd, the
> file system is protected against alteration (r/o mount, or not
> mounted at all). I know there are "snapshots" (as they exist in
> relation with fsck, too), but I don't trust them. Many years ago,
> such a snapshot made it _impossible_ for fsck to do its job. Once
> it was removed, I got my files back (for the price of a few lost
> file names, but still better than nothing).
>=20
Perhaps I misunderstand. I thought journaling was supposed to
*increase* the robustness of a filesystem. It seems to me that what
this amounts to is the contrary.

Thanks!

--=20
David Benfell <benfell@parts-unknown.org>
See https://parts-unknown.org/node/2 if you don't understand the
attachment.

--YToU2i3Vx8H2dn7O
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJT5/TmAAoJEBV64x4SNmArPgYQAIcn8xiWktUOky0iYx6bJAUm
YeqesCwMKZCXgY3ZqHg1Z1d+gdB+ZUYBEmREc5XL4Pn7pr0qphjLMzhPNAsObN4r
BX/Xy08bzb4zEd50tKtl5q9R2baNTMv3ruSf/lDYHJxCxllL44uXNoBSmAsvCqsF
TKqWipHtymYeIZP4MZ9dj3k6Uqw24ZMeFooVcU8lWorCGq4ezrF+HHH3Y+/SpvuC
GhOFeJPmZf37x/tE7Aor2AMOwDWjoQppLk3LrobdYkCPc2BfR98fSaQtZGtOxOaT
YrJgKyaxRgeiQbTJqzajNdJGXoGMth+h9dCULikK/a4AbfxKFPY5dtwcJoTnUbmZ
ZgJDORJWjEwOXjwP1a252HBH/GQinbzbXBtMaJyAUbVSOivFgls0t55IrzIQ3+eS
uDwPRr2INR7qm9A2Y3zgCZHP9X9gTJSid+cMB+DLT1F75Q5avevzbgftKmRd3ziC
j5XscgYYfFhfJ7ICHN82GU1qUblY5Y9WDyfY1j/NGziYjroME8wUdlQPSnVbo46Z
/jHlGts5eNL2fWyGk+tj41tyhp+1BgsJD4rhB+12slD3HJzayNHePvXq+8q81Eaj
j32Ez89OVC/I+Cmq8Ec2m7nfrTUqjTZtJIHIwHx6MNcAi/oGEZcUAxfb2ndbx1yC
k1IkrwZmLGSxYrhLYctv
=F8ks
-----END PGP SIGNATURE-----

--YToU2i3Vx8H2dn7O--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140810224038.GD24036>