From owner-freebsd-stable@FreeBSD.ORG Sat Nov 3 23:03:20 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 7DD5C392 for ; Sat, 3 Nov 2012 23:03:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 453808FC0A for ; Sat, 3 Nov 2012 23:03:19 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.4/8.13.1) with ESMTP id qA3MW8Am075801 for ; Sat, 3 Nov 2012 16:32:09 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Sat Nov 3 16:32:09 2012 Message-ID: <50959B63.9070709@denninger.net> Date: Sat, 03 Nov 2012 17:32:03 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: Why is SU+J undesirable on SSDs? References: <201211032130.PAA04484@lariat.net> In-Reply-To: X-Enigmail-Version: 1.4.5 X-Antivirus: avast! (VPS 121103-1, 11/03/2012), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 23:03:20 -0000 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.) 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. 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. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC