Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 Jan 2002 18:35:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 Jan 2002 18:35:35 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:25363 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Tue, 22 Jan 2002 18:35:18 -0500 Date: Tue, 22 Jan 2002 21:34:56 -0200 (BRST) From: Rik van Riel X-X-Sender: To: Hans Reiser Cc: Chris Mason , Andreas Dilger , Shawn Starr , , Subject: Re: Possible Idea with filesystem buffering. In-Reply-To: <3C4DE825.1030406@namesys.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Jan 2002, Hans Reiser wrote: > Let's try a non-reiserfs sub-cache example. Suppose you have a cache > of objects that are smaller than a page. > Suppose that there is absolutely no correlation in access between the > objects that are on the same page. Suppose that this subcache has > methods for freeing however many of them it wants to free, and it can > squeeze them together into fewer pages whenever it wants to. In this case I absolutely agree with you. In this case it is also _possible_ because all access to these data structures goes through the filesystem code, so the filesystem knows exactly which object is a candidate for freeing and which isn't. I think the last messages from the thread were a miscommunication between us -- I was under the impression that you wanted per-filesystem freeing decisions for things like page cache pages. kind regards, Rik -- "Linux holds advantages over the single-vendor commercial OS" -- Microsoft's "Competing with Linux" document http://www.surriel.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/