From owner-freebsd-questions@FreeBSD.ORG Sun Aug 10 22:40:56 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF1A4190 for ; Sun, 10 Aug 2014 22:40:56 +0000 (UTC) Received: from mail.parts-unknown.org (home.parts-unknown.org [50.250.218.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 938162811 for ; Sun, 10 Aug 2014 22:40:56 +0000 (UTC) Received: from mail.parts-unknown.org (unknown [127.0.0.1]) by mail.parts-unknown.org (Postfix) with ESMTP id 436EF5991D23; Sun, 10 Aug 2014 15:40:45 -0700 (PDT) Received: by mail.parts-unknown.org (Postfix, from userid 1001) id 0EE885991D22; Sun, 10 Aug 2014 15:40:39 -0700 (PDT) Date: Sun, 10 Aug 2014 15:40:39 -0700 From: David Benfell To: Polytropon Subject: Re: operation not permitted on entropy file Message-ID: <20140810224038.GD24036@home.parts-unknown.org> References: <20140810070239.GA80734@home.parts-unknown.org> <20140810103119.GA26958@slackbox.erewhon.home> <20140810124433.da498898.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YToU2i3Vx8H2dn7O" Content-Disposition: inline In-Reply-To: <20140810124433.da498898.freebsd@edvax.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: ClamAV using ClamSMTP on home.parts-unknown.org Cc: Roland Smith , freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 22:40:56 -0000 --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 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--