Date: Sat, 03 Nov 2012 17:32:03 -0500 From: Karl Denninger <karl@denninger.net> To: Jeff Roberson <jroberson@jroberson.net> Cc: Brett Glass <brett@lariat.net>, stable@freebsd.org Subject: Re: Why is SU+J undesirable on SSDs? Message-ID: <50959B63.9070709@denninger.net> In-Reply-To: <alpine.BSF.2.00.1211031224570.1947@desktop> References: <201211032130.PAA04484@lariat.net> <alpine.BSF.2.00.1211031224570.1947@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ®/ <http://market-ticker.org>;
Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50959B63.9070709>