operation not permitted on entropy file

David Benfell benfell at parts-unknown.org
Mon Aug 11 14:27:15 UTC 2014

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:
> The Fast File System (FFS, also called UFS), has several
> iterations and additions:
> 	UFS 1
> 	UFS 2
> 	UFS 2 + Soft Updates
> 	UFS 2 + Soft Updates + Journaling
> See "man newfs" and "man gjournal" for details.
> 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.
> 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... ;-)
 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.

David Benfell <benfell at parts-unknown.org>
See https://parts-unknown.org/node/2 if you don't understand the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20140811/9a081968/attachment.sig>

More information about the freebsd-questions mailing list