Date: Wed, 26 Dec 2007 22:25:05 +0900 From: "Adrian Chadd" <adrian@freebsd.org> To: "Scott Long" <scottl@samsco.org> Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? Message-ID: <d763ac660712260525u7e2c18b8t32904807c549b3c4@mail.gmail.com> In-Reply-To: <4772529D.9010805@samsco.org> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <d763ac660712241820s38237d99x1243862095780dc6@mail.gmail.com> <4772529D.9010805@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/12/2007, Scott Long <scottl@samsco.org> wrote: > Yes, Squid is the ideal application for IFS. Do you still have any of > your work on this, and would you be able to share it? It'd be easy to rewrite it from scratch if IFS were recovered. In fact, the whole point behind IFS, way back when, is I could layer a user-space directory hierarchy on top of a kernel provided space and then do "stuff" (I had a POP3 Maildir-like server written using IFS back then.) The squid code wasn't difficult at all. The biggest problem back then was rebuilding the disk index - didn't I have some code to export the inode allocation bitmap via a special file in the filesystem so I didn't have to stat() each individual inode, or didn't I end up comitting that? I'm happy to work on that later on next year. I've got enough non-disk Squid code to rewrite and optimise over the next few months; the storage side is going to have to wait a while. Adrian -- Adrian Chadd - adrian@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d763ac660712260525u7e2c18b8t32904807c549b3c4>