HEADS UP: SUJ Going in to head today
jroberson at jroberson.net
Fri Apr 23 08:28:43 UTC 2010
On Wed, 21 Apr 2010, Garrett Cooper wrote:
> On Wed, Apr 21, 2010 at 12:39 AM, Gary Jennejohn
> <gary.jennejohn at freenet.de> wrote:
>> On Tue, 20 Apr 2010 12:15:48 -1000 (HST)
>> Jeff Roberson <jroberson at jroberson.net> wrote:
>>> Hi Folks,
>>> You may have seen my other Soft-updates journaling (SUJ) announcements.
>>> If not, it is a journaling system that works cooperatively with
>>> soft-updates to eliminate the full background filesystem check after an
>>> unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled
>>> with tunefs -j disable on an unmounted filesystem. It is backwards
>>> compatible with soft-updates with no journal.
>>> I'm going to do another round of tests and buildworld this afternoon to
>>> verify the diff and then I'm committing to head. This is a very large
>>> feature and fundamentally changes softupdates. Although it has been
>>> extensively tested by many there may be unforseen problems. If you run
>>> into an issue that you think may be suj please email me directly as well
>>> as posting on current as I sometimes miss list email and this will ensure
>>> the quickest response.
>> And the crowd goes wild.
>> SUJ is _great_ and I'm glad to see it finally making it into the tree.
> Indeed. I'm looking forward to testing the junk out of this --
> this is definitely a good move forward with UFS2 :]...
> PS How does this interact with geom with journaling BTW? Has this been
> tested performance wise (I know it doesn't make logistical sense, but
> it does kind of seem to null and void the importance of geom with
> journaling, maybe...)?
A quick update; I found a bug with snapshots that held up the commit.
Hopefully I will be done with it tonight.
About gjournal; there would be no reason to use the two together. There
may be cases where each is faster. In fact it is very likely. pjd has
said he thinks suj will simply replace gjournal. GEOM itself is no less
important with suj in place as it of course fills many roles.
Performance testing has been done. There is no regression in softdep
performance with journaling disabled. With journaling enabled there are
some cases that are slightly slower. It adds an extra ordered write so
any time you modify the filesystem metadata and then require it to be
synchronously written to disk you may wait for an extra transaction.
There are ways to further improve the performance. In fact I did some
experiments that showed dbench performance nearly identical to vanilla
softdep if I can resolve one wait situation. Although this is not trivial
it is possible. The CPU overhead ended up being surprisingly trivial in
the cases I tested. Really the extra overhead is only when doing sync
writes that allocate new blocks.
I am eager to see wider coverage and hear feedback from more people. I
suspect for all desktop and nearly all server use it will simply be
More information about the freebsd-current