This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 19 16:50:15 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id RAA17930 for ; Tue, 7 Mar 2000 17:55:15 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id 522DF59044; Tue, 7 Mar 2000 14:55:04 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Tue, 7 Mar 2000 12:47:38 -0500 Received: by vger.rutgers.edu id ; Tue, 7 Mar 2000 12:42:17 -0500 Received: from idiom.com ([216.240.32.1]:3873 "EHLO idiom.com") by vger.rutgers.edu with ESMTP id ; Tue, 7 Mar 2000 12:17:38 -0500 Received: from idiom.com (reiser.dial.idiom.com [216.240.37.24]) by idiom.com (8.9.3/8.9.3) with ESMTP id NAA83820; Tue, 7 Mar 2000 13:17:47 -0800 (PST) Message-Id: <38C4D911.506FC829@idiom.com> Date: Tue, 07 Mar 2000 13:25:21 +0300 From: Hans Reiser X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en, ru Mime-Version: 1.0 To: "Stephen C. Tweedie" Cc: Jamie Lokier , Alexander Viro , "linux-kernel@vger.rutgers.edu" , "linux-fsdevel@vger.rutgers.edu`" , Kon Subject: Re: Does your change make find faster by changing where it is storedor where it is returned? References: <38C2DAC2.7713713B@idiom.com> <20000306142741.F4819@pcep-jamie.cern.ch> <38C371B5.C48EBB05@idiom.com> <20000307003542.A5916@pcep-jamie.cern.ch> <38C42313.A8C2BD7E@idiom.com> <14532.65158.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig "Stephen C. Tweedie" wrote: > > Hi, > > On Tue, 07 Mar 2000 00:28:51 +0300, Hans Reiser > said: > > > Ok, you may have been wondering where my questions were going, now I > > can explain. > > > You are proposing changing the VFS interface for an ext2 specific > > optimization. > > But it's not! The proposed dentry change is already in widespread use > in other Unixen. The user-visible structure field (d_type in struct > dirent) is already present in glibc. The proposal, then, is to use a > field which already exists but which is currently always set to a null > value because the kernel API doesn't pass it back. ext2 is currently > the only Linux filesystem which supports that field, but it's definitely > not an ext2-specific innovation. > > > That is, I propose that instead you make it possible to access any piece of > > stat-meta-data without having to access the other pieces of metadata. stat() > > forces you to access everything, and sometimes you don't want everything. > > Possibly, but the stat() way of doing things has its own problems: it > required an inode lookup internally, which basically requires an > unconditional iget, and it only returns one item at a time. Directory > scanning is a lightweight operation which doesn't need to pull in > metadata, except when you want to scan an entire tree. In that case, > the only thing you care about is whether a dirent is a subdirectory or > not, which is why the dentry type is valuable at that point. > > --Stephen I didn't say, do the meta-stat-data access with an iget, I meant let the FS decide how to do it. If it does it with iget, fine, but what I want to see is a general interface which can access arbitrary non-filebody data (which the FS can store where it chooses and fetch how it chooses). This way we can handle ACLs and other things as yet undreamt of in a symmetrical manner. We'll produce some code to do this sometime in the next year I think, and then put it out for comment and review. You and James provided good answers to the issues I was concerned about, I guess I just lack enthusiasm for more changes to VFS interfaces while we are trying to port to the changes already made, and I am wrong in this.  Best, Hans -- You can get ReiserFS at http://devlinux.org/namesys, and customizations and industrial grade support at reiser@idiom.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/