Date: Sat, 7 Oct 2000 10:40:10 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Alex Povolotsky <tarkhil@over.ru> Cc: "Michael C . Wu" <keichii@peorth.iteration.net>, freebsd-fs@freebsd.org Subject: Re: Specialised storage system? Message-ID: <Pine.NEB.3.96L.1001007103437.74808A-100000@fledge.watson.org> In-Reply-To: <20001007130626.A30963@mail.over.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 7 Oct 2000, Alex Povolotsky wrote: > On Sat, Oct 07, 2000 at 03:02:02AM -0500, Michael C . Wu wrote: > > But I think, as others have said, a database oriented system like > > squid/inn or a real db would probably work better. > AFAIK, all FFS-based systems suffers from relatively low metadata > performance, and most oftem mails are read ONCE before deletion. Thus, I > think that specialised mail storage will yield better performance. FFS is slow for meta-data because it provides strong failure-resistent consistency guarantees for its namespace. As I have pointed out several times, if those guarantees are too strong to your needs, you should fall back on FFS only as an intelligent backing store for integer-named files, and then provide your own meta-data storage, probably in one of the early files on the partition. The UNIX message format (one file per mailbox) is certainly something you want to avoid, but once you throw out the naming and directory system, the inode->file mechanism is quite a decent approximation of message behavior (cheap create, delete, write-once, read-many operations), and as I think Terry pointed out, you can reallocate block and indirect block pointers in the inode based on your expected message size. You can then use a file-based database to store mail folder meta-data, probably one folder per file, perhaps allocating the first file inode to be an index of folders (or something else depending on contention). You could even use dbm or something, although that scales poorly to large database write operations. Since the messages tend not to have modify/extend/shrink operations, you even have really nice fragmentation properties. But I'd definitely attempt to keep the meta-data logic for folder indexes and so on in userland, and rely on a more general backing store. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.NEB.3.96L.1001007103437.74808A-100000>