From owner-freebsd-stable@FreeBSD.ORG Sat Nov 1 18:52:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78542D4A; Sat, 1 Nov 2014 18:52:30 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 383478FD; Sat, 1 Nov 2014 18:52:30 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id a13so2692773igq.17 for ; Sat, 01 Nov 2014 11:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gZrgM9n7+X7udI18yJtIy9BrYql3fzFLhh2ui3p+IMw=; b=sz8pT5XW4XOvecc2rANRUOjlKvtgba7iXPlcKrEyD70sNQu7OFK6T7vEsU7YDTINZz g0o4j5/3bgOLpqRyjo0xKGeB/eXNlWAR++IY9Sx9eElcfCVkrOSTQ/axnLU4rwdhkxiL UxH2q6uw7kumcTEa8M4v9mOx+/ikHw9AEueNIrtfVfiCJQqbQ/zrdhTz+Mu8OskBAO1J UKSZTBhDqZmkCsyznjBltKjU9aCVhfUcttHZHKQPGN0UtsczwJGXd3XaSC5Cqcy/VlGc kX4sTpT7YkHYtHv3g/4ldlIEoiql2Z6a/i2FFsGloZgQxWwypQ4TlCkms2uxwfVWemRZ oB/A== MIME-Version: 1.0 X-Received: by 10.50.117.71 with SMTP id kc7mr5497282igb.35.1414867949559; Sat, 01 Nov 2014 11:52:29 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Sat, 1 Nov 2014 11:52:29 -0700 (PDT) In-Reply-To: References: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> <20141025113846.GY1235@albert.catwhisker.org> <6bb4cda435fb420fb663fa1d47b85a08@ultimatedns.net> <9c5f3b0230bf63d32ee8a83e81b1f167@ultimatedns.net> Date: Sat, 1 Nov 2014 11:52:29 -0700 X-Google-Sender-Auth: nZxglLNgTZ3saa3hFizfj4ymWSk Message-ID: Subject: Re: Dump time issues From: Kevin Oberman To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 18:52:30 -0000 On Sat, Nov 1, 2014 at 11:47 AM, Kevin Oberman wrote > On Fri, Oct 31, 2014 at 8:10 AM, Chris H wrote: > >> On Tue, 28 Oct 2014 12:20:01 -0700 Adrian Chadd >> wrote >> >> > On 27 October 2014 11:09, Kevin Oberman wrote: >> > >> > >> I'm aware of two issues with SU+J, one of which is annoying and the >> other >> > > is worse. >> > > 1. If the journal is not fully written on power fail or some other >> reason, >> > > you may need to do a full fsck of the volume and the behavior of the >> system >> > > until this is done can be very unpredictable. >> > > 2. You can't safely snapshot the system. This is what 'dump -L' does. >> This >> > > means that some files dumped from a live FS may not be consistent (not >> > > good!) or, if '-L' is used, the system may well hang. >> > > >> > > While I love the fast fsck times (2 or 3 seconds) after a crash, I >> also >> > > question the default. Still, it may be a preferred choice be used for >> very >> > > large file systems where a full fsck would take a very long time as >> long as >> > > the risks are understood. For these systems, ZFS might be a better >> choice. >> > > These arguments do NOT favor it being the default, IMHO. >> > >> > If people can reproduce SU+J problems then please file bugs. There >> > have been some fixes with the journal handling over the last year or >> > so and I haven't had this problem on -HEAD any longer, but it doesn't >> > mean it's there. >> Problem existed on RELENG_9 as of 1 mos, and 1 wk. ago. I don't >> have any useful output to provide (I simply blew away the system >> && re-installed w/o SU+J). >> >> --Chris >> > > You should be to deal with that using "tunefs -j disable". Much easier > than re-installing. > > Would disabling soft updates journaling, snapshotting, and re-enabling > would work around the issue? I might play with this when I get a chance. If > it works, perhaps tools (mostly dump -L) could check for SU+J and turn it > off for the time to snapshot the file system. I'm just not sure how well > re-enabling works. Certainly some journal data would be lost, but the > snapshot operation should make that irrelevant. I just don't know that I > understand the details of SU+J well enough to know whether this would make > sense. > Memo to self: Don't type stupid responses while watching football games! Enabling/disabling soft updates journaling requires unmounting the file system, and re-mounting after the change. In the case of root (or a single file system), it would require a reboot. A bit too intrusive for many cases. Why do I realize these things a few seconds AFTER hitting "Send"? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com