Date: Mon, 11 Nov 1996 08:25:09 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: hgoldste@bbs.mpcs.com Cc: freebsd-isp@freebsd.org, freebsd-fs@freebsd.org, dg@root.com, michaelv@MindBender.serv.net Subject: Re: Best mount options, tunefs for newsserver Message-ID: <199611111425.IAA19231@brasil.moneng.mei.com> In-Reply-To: <199611111259.HAA31462@bbs.mpcs.com> from "Howard Goldstein" at Nov 11, 96 07:59:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Would be neat to have a new class of filesystem, call it "expfs" > (expendable filesystem) for low-value high-volume stuff like news > articles. Could have default async writes, noatime, preferred time > optimization, anything else that would lend itself to this sort of thing. Oh, boatloads :-) One big win in general would be an extension to FFS to allow some sort of sorted or hashed directory, which would be useful for directories with lots of files (not just news spool, think about large mail spools, etc). News in particular could stand to have its very own type of filesystem, since it has lots of things that can be optimized for. Consider changing the news directory behavior on a news spool. You have two types of data, subdirectories and articles. In general isdigit(element[0]) is a good first guess at which type of directory entry it is, so now consider the following: A portion of the "directory" is reserved for subdirectories. Since it is not often updated with new entries, it is considered to be acceptable to maintain it as a sorted list, or some other method (hashing perhaps) to allow rapid binary tree style lookups. A portion of the "directory" is reserved for news articles. Usenet news articles have fascinating properties: they are written in numerically ascending order, and tend to be erased in the same fashion. Adding a new file need be only as complex as knowing the offset of the last entry written and checking against it to make sure that the new entry is higher (if not, one would need to shuffle the directory to "make it right"). Removal simply zeroes the entry; empty directory blocks can be freed. As a further twist, the "article" entries are stored in native integer format as opposed to ASCII "string" format, allowing comparisons to happen even more rapidly. Now we have mechanisms in place for extremely fast lookup operations and write operations. If only I had the hours in the day to learn how to write my own file systems... FFS is excellent as a general purpose file system, but it lacks the ability to take advantage of these types of things. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611111425.IAA19231>