From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 22:41:41 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D72870E for ; Sat, 3 Nov 2012 22:41:41 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id E807F8FC08 for ; Sat, 3 Nov 2012 22:41:40 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3342727pad.13 for ; Sat, 03 Nov 2012 15:41:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=/aoaYnatAV1Amhlt/ro9fkE7nusT1NO1ieYMzakVoZY=; b=YQycFSRW42yE9DPEwAtQa7qEI/be+nUO9UV6GHblZzDVQm6YDstK4kfHPZNwVKxipm MpMHXLzFCDJeKvYQmhdQyfV/97GvFPVh/4j7I5jCWda2NlgzL4byc0ULKrnU6UXKFXG3 EmYC2N3J8HE6RTbbPTw/N+9N2UdaQWCyYfTB2r5cggW2NhI+To/+9Bui6yH9iemdnNp+ Le8wFSvH+yn/gzVwBv5Zs5hx+VVTEMmIPpnfTys7PSnAncsrCAGrw/ZGkw3QQE6D29du R3xZ35Nz/4SYo/eeuverU1evDyKMDFVpGgC3h5smK+O7c/zpxauWBWS44zt9CWG9I6jg pA5A== Received: by 10.68.226.67 with SMTP id rq3mr18089901pbc.121.1351982500581; Sat, 03 Nov 2012 15:41:40 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id ph7sm6525171pbb.9.2012.11.03.15.41.39 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 15:41:40 -0700 (PDT) Date: Sat, 3 Nov 2012 12:40:16 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Karl Denninger Subject: Re: Why is SU+J undesirable on SSDs? In-Reply-To: <50959B63.9070709@denninger.net> Message-ID: References: <201211032130.PAA04484@lariat.net> <50959B63.9070709@denninger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1174873047-1351982418=:1947" X-Gm-Message-State: ALoCoQmyuoMhDh1caL0O9ncbN3g4yHShyur6YprK40s4XoqM8NAYsWoLO78a46EIiAiI+PHox2lY Cc: Brett Glass , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Nov 2012 22:41:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1174873047-1351982418=:1947 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 3 Nov 2012, Karl Denninger wrote: > > On 11/3/2012 5:25 PM, Jeff Roberson wrote: > On Sat, 3 Nov 2012, Brett Glass wrote: > > Have been following the thread related to SU+J, and > am wondering: why is it > considered to be undesirable on SSDs (assuming that > they have good wear > leveling)? I have been enabling it on systems with > SSDs, hoping that between > the lack of rotating media and the journaling I > would have very robust > systems. > > > I know of no reason to support this notion.  Although SSDs are > so fast you might be happy to wait for the fsck time in exchange > for snapshots. > > Jeff > > > It is utter insanity to enable, by default, filesystem options that break > the canonical backup solution in the handbook ("dump", when used with "-L", > which it must be to dump a live filesystem SAFELY.) I did not enable it by default but it makes sense for desktop users who are probably not often using dump/restore. I agree that the option should be covered in more detail. > > IMHO either snapshots with journaling needs to be fixed, some other > canonical and reasonably-implemented means of backups that actually works > and is as robust as dump must be made available, tested and documented at > the level that dump has been (good luck with that!) or +J has to be removed > as the default. We are hopefully fixing snapshots in current and I would expect it to be ready for backport in the 9.2 timeframe. It is next on the list after we fix the drive write cache problem for mobile users who may lose power frequently. > > I love "progress" as much as the next guy but my first requirement for an > operating system is that it not irretrievably lose my data. I hear your frustrations but please try to express it more productively in the future. Thanks, Jeff > > -- > -- Karl Denninger > The Market Ticker (R) > Cuda Systems LLC > > --2547152148-1174873047-1351982418=:1947--