Date: Tue, 22 Dec 2009 13:35:52 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Andrew Snow <andrew@modulus.org> Cc: freebsd-fs <freebsd-fs@freebsd.org>, jeff@FreeBSD.org Subject: Re: Plans for Logged/Journaled UFS Message-ID: <alpine.BSF.2.00.0912221328350.1027@desktop> In-Reply-To: <4B302A6D.3000408@modulus.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> <4B302A6D.3000408@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Dec 2009, Andrew Snow wrote: > > Is there any provision to put the journal on a seperate device? This can > solve the performance degradation issue. Currently there is no plan for it. The amount of journal data is so small compared to typical journaled filesystems I don't think we'll see a significant slowdown due to the journal writes. Consider the operation of creating a new file. We must write a cyl group to allocate a bitmap, an inode block to initialize the new inode, a directory block to add the entry, and potentially the directory inode to update timestamps, directory size, etc. So 4 block size writes if there is no directory allocation. The journal adds one 32byte entry to a block size write that can commonly hold 512 entries if you can aggregate them. Another way to look at it is that you can create 512 files (ignoring directory block allocation) before you need to write the journal. With full metadata block journaling you're writing the full size of each of those 4 blocks every time a change is made. On a 16k block filesystem that's 64k vs our 32 bytes. We can accomplish this because the recovery operation is smart enough to parse all the metadata and see how far along the operation is. Softupdates orders writes well enough that we only have to handle a small number of failure cases and can make big assumptions about the state of the filesystem. If any of these assumptions are not true we still have a full fsck to fall back on. Thanks, Jeff > > > - Andrew > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0912221328350.1027>