Date: Fri, 26 Feb 1999 18:56:39 -0500 (EST) From: Alfred Perlstein <bright@cygnus.rush.net> To: freebsd-fs@freebsd.org Subject: question about LFS design. Message-ID: <Pine.BSF.3.96.990226183659.7848X-100000@cygnus.rush.net>
next in thread | raw e-mail | index | archive | help
I've been reading the 4.4 book, and several other kernel algorithm books fora few months. Many topics interest me, one particular idea i just had is not very revelant to freebsd (LFS is gone). BUt i'd like to tap into the experiance and knowledge available in this forum. What i was wondering is if the *BSD LFS design has ever been fitted with an addtional interface for the LFS cleanerd to make it much more effecient (imo). It would involve adding another kernel entry point for lfs: lfs_getrealloc() As the kernel is forced to use the log which may become fragmented it records "read faults". "Read faults" in this sense occur when a sequence of blocks that are read by an application for the LFS to seek more than twice for the data, meaning fragmnetation has occured. The kernel will remeber where these read faults happened (which segments) contained fragmented blocks, it will then sort these based size / frag ratio (best guess) And try to write out the data continuously in the next segment. The cleaner should know about this, it gives the cleaner a better idea of where waste is happenening so it can act correctly. Perhaps lfs_getrealloc() isn't enough, the kernel should do statistic gathering on dirtied buffers as well. Instead of the cleaner blindly reading segments and passing them to the kernel for even more processing, the kernel can provide a strong hint to the cleaner as to "what needs to get done". Instead of a LRU, a time VS size list would work better that way the kernel is more apt to notify the LFS of large chances for block reclaims than a strick LRU. maybe a better name for the entry point: lfs_getwritev() which returns segments containing blocks and inodes that have been modified? Is anyone aware of this being tried in any impelementation? thank you, -Alfred 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.3.96.990226183659.7848X-100000>