operation not permitted on entropy file
rsmith at xs4all.nl
Mon Aug 11 01:15:11 UTC 2014
On Sun, Aug 10, 2014 at 03:40:39PM -0700, David Benfell wrote:
> > > Trying to make a backup in this state will probably not work.
> > 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).
A problem surfaced in the 8.x - 9.x timeframe where dump(8)-ing a live
filesystem (which is done via a snapshot) would hang. At that time the advice
was to not make live dumps but to make dumps in single user mode.
I'm not sure if the problem was found and rectified yet. I've been making
dumps in single user mode ever since, just to be safe.
> 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.
Well, UFS (a.k.a. ffs(7) ) doesn't have journaling as such. It does have
journaling for *soft updates*. The basic purpose of journaling in this
case is to reduce the time to run an fsck. And that works very well.
When making backups I drop my system to single user mode and every now and
then I run a *full* fsck of every filesystem before running dump(8).
But I must say that this usually doesn't find serious problems. The only real
causes of filesystem corruption that I have encountered have basically been;
* dying HDDs
* repeated crashes (often also hardware related; memory, power supply,
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 5753 3324 1661 B0FE 8D93 FCED 40F6 D5DC A38A 33E0 (keyID: A38A33E0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the freebsd-questions