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 :]... > Cheers, > -Garrett > > 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 transparent. Thanks, JeffReceived on Fri Apr 23 2010 - 06:28:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC