Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 03 Nov 2012 17:52:42 -0600
From:      Brett Glass <brett@lariat.net>
To:        Jeff Roberson <jroberson@jroberson.net>, Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        Adam Vande More <amvandemore@gmail.com>, stable@freebsd.org
Subject:   Re: Why is SU+J undesirable on SSDs?
Message-ID:  <201211032352.RAA05658@lariat.net>
In-Reply-To: <alpine.BSF.2.00.1211031311280.1947@desktop>
References:  <201211032130.PAA04484@lariat.net> <CA%2BtpaK2z7LPG3_ys17RYcs8fefC=o=xM5GSEcze_gCZ8qoBWxw@mail.gmail.com> <1351983269.1120.137.camel@revolution.hippie.lan> <alpine.BSF.2.00.1211031311280.1947@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
At 05:14 PM 11/3/2012, Jeff Roberson wrote:

>The journal entries are 32 bytes per in SUJ.  So the number of 
>extra writes is down in the noise.  The journaling also gets you 
>asynchronous partial truncation and a few other asynchronous 
>operations that are sync in SU.  It does cost slightly more cpu 
>time and more memory.  I'm not saying you're making the wrong 
>choice.  I'm just saying that it's not clear that you should or 
>should not use it with SSDs.

This is what I would expect, and with wear leveling it is unlikely 
that the wear on the SSD would be significant anyway. In my case, 
the most important thing is not to lose logs in a crash (which 
could happen with just fsck), so journaling is worth it for me.

The only reason I could see not to use SU+J with SSDs (or any disk, 
for that matter) is if there are bugs which harm stability. A look at

http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=open&sort=none&text=&responsible=&multitext=&originator=&release=

shows several open PRs mentioning panics, corruption, and reboots. 
Are they still open because problems exist? Or have the committers 
simply neglected to close them?

--Brett Glass




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