Date: Thu, 21 Sep 2000 18:22:28 +0200 (CEST) From: Marius Bendiksen <mbendiks@eunet.no> To: Dwight Tuinstra <tuinstra@clarkson.edu> Cc: freebsd-fs <freebsd-fs@FreeBSD.ORG> Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) Message-ID: <Pine.BSF.4.05.10009211808360.39384-100000@login-1.eunet.no> In-Reply-To: <39CA26D7.51D314BF@clarkson.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> As a long-term graduate research project, I've been looking into > the code for LFS (Log-structured File System) on NetBSD. Such a > system is optimized for many small writes, and given the amounts > of RAM available for read caches nowadays, should deliver read > performance comparable (or not much worse) than FFS. Additionally, > LFS should provide better and faster crash recovery than either FFS > or journaling file systems. Research (IIRC, Seltzer and Matthews) has shown that FFS outperforms LFS when the FFS clustering code has been activated. The crash recovery times can supposedly be alleviated by soft updates, I've not looked at that yet. Journalling crash recovery vs LFS crash recovery is more complex than a mere comparison of speed, as these can be tuned in both cases. > In a nutshell, the difference between journaling file systems > and LFSes is that jFSes keep a log of metadata, whereas an LFS > keeps metadata AND data in a unified log structure (and yes, this > means playing lots of tricks with how inodes are located and found). Tricks that should be avoided. The idea of unifying the log is good, IMO. However, locating an inode through the reading of indirect blocks, as will be the case, is not the best approach for large file systems. Also, the problem remains that you may lose locality of reference in time, as inodes will always follow their inode block, not their data blocks. I have a solution for this problem, but am prohibited from providing it due to using it in connection with a commercial venture. > At present, the only working, available LFS system (that I'm aware > of) for a freeNIX is the one in NetBSD, though there are at least two > efforts underway for Linux. There is an order of magnitude > improvement in the write times for their "pkgsrc" directory > (equivalent to the FreeBSD "ports" directory) when comparing > FFS to LFS. The NetBSD LFS code is still beta, but in pretty good > working order. This is simply because the directory structure is written contigously to the log, rather than being scattered. You would see the same benefit on the predecessor to FFS, which didn't do round-robin scattering of the directories. My preferred (among the simple ones) solution to this, is maintaining small directories in a cluster at the centre of the disk. > There has been controversy regarding the performance claims > of LFS under various disk activity patterns. The research I'll be > doing aims to investigate the claims, especially after implementing > the optimizations proposed by Matthews et al (Improving the > Performance of Log-Structured File Systems With Adaptive Methods; > Proc. Sixteenth ACM Symposium on Operating System Principles). > Dr. Matthews is my advisor on this research. Please look into his comparisons with FFS clustering code. > Is there any interest in porting/redesigning LFS for FreeBSD? I am working on a bsdl effort of my own which does not employ logging, and thus will not be able to contribute in the near future. But I would certainly like to be kept up to date, as I am certainly interested. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10009211808360.39384-100000>