Date: Mon, 08 Oct 2007 11:49:46 -0400 From: Stephan Uphoff <ups@freebsd.org> To: Eric Anderson <anderson@freebsd.org> Cc: freebsd-current@freebsd.org, d@delphij.net, Philip Murray <pmurray@nevada.net.nz>, Antony Mawer <fbsd-current@mawer.org> Subject: Re: GJournal Message-ID: <470A519A.5030708@freebsd.org> In-Reply-To: <470445EB.2040401@freebsd.org> References: <AFC6218B-22C8-4489-9390-C8D083B0E24A@nevada.net.nz> <47041B1D.8060900@delphij.net> <47043B71.1@mawer.org> <470445EB.2040401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > Antony Mawer wrote: >> On 4/10/2007 8:43 AM, LI Xin wrote: >>> Philip Murray wrote: >>>> Hi, >>>> >>>> I've got a 3TB volume that I really really want to avoid fscks on >>>> (they're taking 4-5hours on an exist 1.5TB volume) so Gjournal is >>>> looking good. >>>> >>>> Is it possible to make it only journal meta-data? Instead of data and >>>> meta-data (ie, like XFS, ext3 by default etc), it seems like you'd >>>> take >>>> less of a performance hit due to not having to write all the data >>>> twice. >>> >>> Not now. gjournal now acts as a block-level journal provider which >>> does >>> not distinguish between meta-data and file data. >> >> Has anyone heard any more information on "BLUFFS" - the "BSD Logging >> Updated Fast File System" that was mentioned at the May 2007 >> Developer Summit? The only information I have been able to find is >> the PDF slides from the presentation, which are here: >> >> http://people.freebsd.org/~ups/pubs/asiabsdcon2007/asiabsdcon_slides_2007.pdf >> >> >> The last slide states the anticipated testing date as Q1, slipped to >> Q2... we are now in Q4 and the only thing I can find on BLUFFS is >> said PDF above. >> >> I do hold out hope for a proper journalled FS for FreeBSD, as while >> ZFS is brilliant in many regards, it is very memory-heavy and as such >> not suitable for all applications... at the same time, UFS is >> reaching the stage where larger filesystems take hours or even days >> to fsck, or sometimes fail altogether from lack of memory. While >> gjournal does provide a partial solution, the penalty from having to >> write the data out to disk twice is a limitation... > > Last I heard from ups@, he was slammed with other things so BLUFFS was > temporarily on hold. > > Eric > > Unfortunately this is still true. While this is my personal priority and I plan to spend substantial time on bluffs the next months I can't promise that this will actually happen. Stephan Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?470A519A.5030708>