From owner-freebsd-questions@FreeBSD.ORG Mon Aug 11 14:27:15 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 8B486602 for ; Mon, 11 Aug 2014 14:27:15 +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 639082FFD for ; Mon, 11 Aug 2014 14:27:14 +0000 (UTC) Received: from mail.parts-unknown.org (unknown [127.0.0.1]) by mail.parts-unknown.org (Postfix) with ESMTP id E9AED598D673; Mon, 11 Aug 2014 07:27:07 -0700 (PDT) Received: by mail.parts-unknown.org (Postfix, from userid 1001) id CFF6F598D5F6; Mon, 11 Aug 2014 07:27:07 -0700 (PDT) Date: Mon, 11 Aug 2014 07:27:07 -0700 From: David Benfell To: Polytropon Subject: Re: operation not permitted on entropy file Message-ID: <20140811142707.GA10186@home.parts-unknown.org> References: <20140810070239.GA80734@home.parts-unknown.org> <20140810103119.GA26958@slackbox.erewhon.home> <20140810124433.da498898.freebsd@edvax.de> <20140810224038.GD24036@home.parts-unknown.org> <20140811101822.41851cc7.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20140811101822.41851cc7.freebsd@edvax.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: ClamAV using ClamSMTP on home.parts-unknown.org Cc: 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: Mon, 11 Aug 2014 14:27:15 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 11, 2014 at 10:18:22AM +0200, Polytropon wrote: > On Sun, 10 Aug 2014 15:40:39 -0700, David Benfell wrote: > > On Sun, Aug 10, 2014 at 12:44:33PM +0200, Polytropon wrote: >=20 > The Fast File System (FFS, also called UFS), has several > iterations and additions: >=20 > UFS 1 > UFS 2 > UFS 2 + Soft Updates > UFS 2 + Soft Updates + Journaling >=20 > See "man newfs" and "man gjournal" for details. >=20 > UFS 1 isn't being used anymore, UFS+SU is the default for > everything except the / partition (no SU there), and +J can > be added. As it has been mentioned, along with more safety > it adds more "moving parts" to the file system implementation. > In ultra-worst case, this can lead to (a kind of) data loss. I pretty much followed the default installation. But when fsck was doing its thing, I saw a lot of unexpected SU+J inconsistencies. So I'm a little puzzled here: Someone posted that fsck uses journaling (which seems very adventurous for something that shouldn't be needed often) even when the filesystem doesn't normally. And if I don't have soft updates by default, then why are they being reported by fsck? And for reference, I notice that journaling decisions need to be made *prior* to creating the filesystem. This isn't like ext2->ext3->ext4. >=20 > Keep in mind a system freeze or accidental hard reboot _never_ is > something "normal" or acceptable. There's a reason, and there are > side effects. Performing a system recovery in a _strictly defined_ > environment is the safest way to deal with those cases, both for > diagnostics and for repair. But again, that's just my very individual > opinion. I like those things to be safe and under monitoring instead > of relying on automatisms and magical decisions... ;-) >=20 7:24AM up 21:36, 5 users, load averages: 0.20, 0.29, 0.32 By my recent standards on this server, this is stellar. I'll wait for three more hours to report to the vendor, but the fsck advice seems to have solved the problem. Thanks! --=20 David Benfell See https://parts-unknown.org/node/2 if you don't understand the attachment. --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJT6NK7AAoJEBV64x4SNmArI0IP/jn0cxndgM6UmQWxM30IssAR peutXVHXHKaPWTvE7A8KslUqHqB5mMkmUlC8yqxt0C2Q9btgnhHKYnamJykgIJeb vQxGsxPT9Uj+GDnFo4aOVAypwgcuJAdsjsOI6zRBWnbktUssakD2E+tmfJuKBoc+ eO26uFiBI1cePUDNz+daQ7Nb06mMmdCYmnIhBJqRa8EzHP4/2fYWCDZIaAG6Kttq kXPZFUMpFBMRj7EQylH2OBCH90oZTHFKBYHT7GmnmDugiGkI4d+RHLM7+U6V4JAi VRY72K+lmL39yVRFXj6FHbHIfZNoKxEl+y6HbdWpizUegXTZxvnmYrXyWa8dCCSZ w1/UDjs/Y2kBQ7cF9oVoNz5ExFI226s4vWyulETOOTmVW8HzElHH+j0dDngcuc6i xuDcu4LTdR+fyPGLMKobKQEgBrtG451ugEEqAn3fvx/lYe02l7dCb3+4JrNy6WVu qI7NHAlbbbYQnHQ0p36u1DETH4Hdb+IsnrptDLp+MlURZRaQJ2jQyV0lpGnDTHU+ dISCI7XrYs0AHLXTMECbfexpKkW694yHAHpVYU1SaFlfqFkr9bFibafyDHZvPsoT 9liWqOMd1dmEqn6xfNQsvugQZPUO176O57mHH95NmUXQPpsEIxaj71craL/RrjFW m6TC94BDfrQAs3ARIlWH =i8JR -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--