Date: Mon, 11 Aug 2014 07:27:07 -0700 From: David Benfell <benfell@parts-unknown.org> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org Subject: Re: operation not permitted on entropy file Message-ID: <20140811142707.GA10186@home.parts-unknown.org> In-Reply-To: <20140811101822.41851cc7.freebsd@edvax.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <benfell@parts-unknown.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140811142707.GA10186>