Date: Mon, 11 Aug 2014 10:18:22 +0200 From: Polytropon <freebsd@edvax.de> To: David Benfell <benfell@parts-unknown.org> Cc: freebsd-questions@freebsd.org Subject: Re: operation not permitted on entropy file Message-ID: <20140811101822.41851cc7.freebsd@edvax.de> In-Reply-To: <20140810224038.GD24036@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Aug 2014 15:40:39 -0700, David Benfell wrote: > On Sun, Aug 10, 2014 at 12:44:33PM +0200, Polytropon wrote: > > 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). > > > 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. 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. For illustration: In my particular case, I had a file open in the editor, the file was saved and _not_ altered. Then my system froze (due to a defective GPU, known fact here) and I had to force a hard reboot. After fsck had "corrected" file system defects (usually not critical at all, data loss isn't typical, and sometimes you find your stuff in the "lost+found" directory), the file was present, but zero size (empty file). But I could remember some of it's specific content and ran a grep through the whole disk - right after making sure no writes would appear (mount -o ro -f /home). After 4 hours, I found the block where my data had been. I cut the relevant passage from the 10K block and the world was good again. :-) UFS has several features that prevent data loss and corruption. And fsck is to make sure in case of errors, mild errors can be corrected automatically, but severe errors require user attention, which is intended because a wrong (or automatic) decision could make data recovery harder. There are also very few factors that can prevent fsck from doing what it's supposed to do, and the snapshot thing cam be one of them - but again, that's 0.000001% of cases you'll encounter in reality. 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... ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140811101822.41851cc7.freebsd>