Date: Mon, 21 Dec 2009 14:47:49 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-fs@freebsd.org, jeff@FreeBSD.org, "Pedro F. Giffuni" <giffunip@tutopia.com> Subject: SU+J, journaled softupdates Message-ID: <alpine.BSF.2.00.0912211432020.1027@desktop> In-Reply-To: <alpine.BSF.2.00.0912220000360.73550@fledge.watson.org> References: <712903.15604.qm@web113517.mail.gq1.yahoo.com> <3612709F-15CA-4A59-86B1-2674BAA2936D@gmail.com> <240049.46806.qm@web113517.mail.gq1.yahoo.com> <alpine.BSF.2.00.0912220000360.73550@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Dec 2009, Robert Watson wrote: > I'm CC'ing Jeff Roberson, who perhaps can comment on his on-going project to > merge journaling techniques with soft updates in UFS (which is just meta-data > journaling, but hopefully will address many of the fsck/bgfsck-related > concerns people have). Hi folks, I have blogged a little bit about my plans at http://jeffr_tech.livejournal.com/. Briefly, I have created a small intent journal that works in concert with softupdates to eliminate the requirement for fsck on boot. Instead fsck has been augmented with a recovery process that reads the journal and corrects the filesystem. The recovery process is very quick and scales with the size of the journal, not the filesystem. The journal is enabled with tunefs on an existing ffs filesystem. The filesystem must be clean to enable. The filesystem must be clean before mounting with a legacy implementation but it is otherwise metadata compatible. A legacy fsck will destroy the journal but otherwise there are no other problems. Presently the code does not support non-journaled softupdates but I will rectify that. Peter Holm (pho@) has been helping me test and once I've fixed the final bugs revealed by his stress2 suite I will make a release and provide instructions. I'm hoping many people will be interested so we can quickly get to some confidence with the patch. One thing to keep in mind is that at runtime this can only slow down softupdates. It is additional overhead which I have attempted to minimize but there is no way around it. To eliminate fsck you must pay a price. This also can not cope with disks that lie about write ordering coupled with power failures. In this case the normal fsck can recover the file system. Cheers, Jeff > > Robert N M Watson > Computer Laboratory > University of Cambridge >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0912211432020.1027>