Date: Wed, 09 Feb 2005 20:23:19 -0700 From: Scott Long <scottl@freebsd.org> To: "Loren M. Lang" <lorenl@alzatex.com> Cc: freebsd-fs@freebsd.org Subject: Re: Journalling FS and Soft Updates comparision Message-ID: <420AD3A7.3000102@freebsd.org> In-Reply-To: <20050210030119.GD29396@alzatex.com> References: <20050210030119.GD29396@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Loren M. Lang wrote: > Traditionally, filesystems have been designed with the idea that the > data will always be written to disk safely and not much effort was put > into making then > > Journalling Filesystems and Soft Updates are two different techniques > designed to solve the problem of keeping data consistent even in the > case of a major interruption like a power blackout. Both work solely on > the meta data, not the real data. This isn't always true. There are journaling implementations that journal the data as well as the metadata. > This means increasing a file's size > is protected, but not neccessarily the data that's being written. (Does > this also mean that the data will be written to free space before the > file size is increased so extraneous data won't be left in the file?) > Journally works be recording in a special place on the hard drive called > the journal every meta data change that it is about to execute before it > does it, then it updates all the meta data and finally marks the journal > completed. Soft updates are simply a way to order meta data so that it > happens in a safe order. An example is moving file a from directory x to > directory y would first delete file a from dir x, then add it to dir y. > If a crash happens in the middle, then the data becomes lost right? > Part of the reordering of metadata in softupdates involves generating dependency graphs that prevent data loss like this. > Now this shouldn't be a big deal since it's harmless to anything else, > just some free space is eaten up. Since all meta data updates have this > same kind of harmless behavior, that why fsck can be done in the > background now instead of foreground. The theory of softupdates is that whatever metadata made it to disk before shutdown/crash is consistent enough to be trusted after just a quick preen. The rest of the background checking is just to clean up blocks that became unallocated but weren't committed. > > Now comparing the two, perfomance wise journalling has an advantage > since every group of meta data updates that are written to the journal > at the same time can be reordered to optimize the disk performance. The > disk head just has to move across the disk in order instead of seeking > back and forth. Now this performance is usually lost because the > journal is constantly needing to be updated and it probably lies in one > small ares of the disk. The other benefit of the journal is very quick > fsck times since all it has do to it see what the journal was updating > and make sure it all completed. Soft updates still require a full fsck, > but since it can be done in the background unlike journalling, it mean > even faster startup time, but more cpu and i/o time spent on it. Now if > the journal of a journalling fs could be kept somewhere else, say, in > some kind of nvram, then journalling might be overall more efficient as > far as disk i/o and cpu time than soft updates. Performance between softupdates and journalling is still hotly debated, and your statements border on the 'flaimbait' side of the argument. > > I'm mainly just trying to get an understanding of these two techniques, > not neccessarily saying one is better. In the real world, it's probably > very dependent on many other things like lot of random access vs. > sequential, many files and file ops per seconds, vs. mostly read-only > with noatime set, etc. Softupdates really aren't a whole lot different from journalling. Both turn metadata operations into a sequence of ordered atomic updates. The only difference is that journalling writes these updates to the on-disk journal right away and then commits them later on, and softupdates keeps (most of) them in RAM and then commits them later on. You are correct that journalling has a key advantage in that a fsck, either foreground or background, is not strictly required after an unexpected shutdown. For further information, I'd suggest reading: http://www.mckusick.com/softdep/index.html Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?420AD3A7.3000102>