From owner-freebsd-stable@FreeBSD.ORG Sat Nov 1 18:47:24 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 40E9BA0B; Sat, 1 Nov 2014 18:47:24 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 07198829; Sat, 1 Nov 2014 18:47:24 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tr6so3221757ieb.28 for ; Sat, 01 Nov 2014 11:47:23 -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=xVPnOG4RxIucGnQJJoqZbED2UlV373QqHOnp9P4XwG8=; b=ZFS4T6NH4BUiDTxmLeeAm44ZuLwh5GKLlLCVb8tRWNuF4k9pojjOc7bLMWkhhkIYSg xsh4uY7qhNRkygjTWFuKKCeJecrnBmvGSRUWv0bdZNg3eDtJDTaal8vjKQZ6du9dnBvq RXs4h9BXPy7oZMMumfmwSB0cP5UiFwbXyzX5Mo7pBUPYGYIJdu4zkcKv++GmeViuL02i pBVUZXhrpDk7I6K3b4pVOLN6P5cypANP8xrTekTwMpI21MwwLn6aSl5olla7Kmhri8Vv cOZZWo6ZoyySPSX9xXsemACHDiHv11HtN2N/u9qbsYu1ByKh3YJRteQ+dJjTilRCd6jI e2jA== MIME-Version: 1.0 X-Received: by 10.42.25.204 with SMTP id b12mr31046992icc.14.1414867643259; Sat, 01 Nov 2014 11:47:23 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.11.152 with HTTP; Sat, 1 Nov 2014 11:47:23 -0700 (PDT) In-Reply-To: <9c5f3b0230bf63d32ee8a83e81b1f167@ultimatedns.net> 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:47:23 -0700 X-Google-Sender-Auth: 8wmA8putkKjEUrjjPUuOpjIFsOg 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:47:24 -0000 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. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com