Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Nov 2012 12:40:16 -1000 (HST)
From:      Jeff Roberson <jroberson@jroberson.net>
To:        Karl Denninger <karl@denninger.net>
Cc:        Brett Glass <brett@lariat.net>, stable@freebsd.org
Subject:   Re: Why is SU+J undesirable on SSDs?
Message-ID:  <alpine.BSF.2.00.1211031233210.1947@desktop>
In-Reply-To: <50959B63.9070709@denninger.net>
References:  <201211032130.PAA04484@lariat.net> <alpine.BSF.2.00.1211031224570.1947@desktop> <50959B63.9070709@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
  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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1211031233210.1947>