From owner-freebsd-questions@FreeBSD.ORG Mon Aug 11 08:18:29 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBDC9F56 for ; Mon, 11 Aug 2014 08:18:28 +0000 (UTC) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9988B204A for ; Mon, 11 Aug 2014 08:18:28 +0000 (UTC) Received: from r56.edvax.de (port-92-195-111-1.dynamic.qsc.de [92.195.111.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id 787F83CEC4; Mon, 11 Aug 2014 10:18:23 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id s7B8IM7P002281; Mon, 11 Aug 2014 10:18:22 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Mon, 11 Aug 2014 10:18:22 +0200 From: Polytropon To: David Benfell 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> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 08:18:29 -0000 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, ...