From owner-freebsd-arch Tue May 14 10:33:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 663A937B401 for ; Tue, 14 May 2002 10:33:10 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g4EHWdb5072785; Tue, 14 May 2002 13:32:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 14 May 2002 13:32:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: arch@FreeBSD.org Subject: Re: Future of IFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 14 May 2002, Julian Elischer wrote: > I have used IFS as a squid cache seeverla times ad I was in teh process > of evaluating it for a project at the moment. Please let us know how that evaluation goes. As I said, I've seen past results (circa early 90's) that suggest this model can be highly effective at reducing cost for namespace-free filestore environments, but given a lack of more recent material evidence, it's hard to talk effectively about IFS. > I have not used it in the last year butI was planning on using it if my > tests work.. (I am on vacation and thus the testing is suspended) > > In my talks with Adrian last week in Perth he indicated that he is > preparing to return to FreeBSD within the next few weeks and resume his > work as squid maintainer as well.. (he was 'on sabatical' while moving > house and starting university) My impression from my conversation with him was that if he did start maintaining IFS again, it would be a re-implementation for 5.0. I'm concerned that in its current state, we will be unable to make progress on UFS2. So I think there are two alternatives: (1) We disconnect it from the build and let it rot in 5.0-CURRENT until he (or someone) fixes it, or that we determine that's not happening by 5.0-RELEASE, and remove it. This is pretty low-cost for us. (2) We remove it from 5.0-CURRENT entirely until he re-adds it. This is also low-cost for us. Given the intent he expressed, I'd prefer (2) so we can make as much progress on UFS2 as we can--given that IFS is highly "in bed" with UFS, it may need re-implementing regardless. If you're in closer contact with Adrian, could you ping him on his time-table for restarting work on IFS? If he does plan on re-implementing, stripping from 5.0 doesn't hurt us (or him), but it will facilitate UFS2 work, which in the long term will benefit IFS as IFS can be updated to use the UFS2 implementation and the abstraction improvements brought in. Another thing to keep in mind here is that we'll be divorcing the ext2fs bits from the UFS bits since UFS will decreasingly provide a useful starting point for the ext2fs implementation. It might be that using the same strategy for IFS would also make sense. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message