Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752435AbbEPOTU (ORCPT ); Sat, 16 May 2015 10:19:20 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:60135 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092AbbEPOTS (ORCPT ); Sat, 16 May 2015 10:19:18 -0400 Date: Sat, 16 May 2015 15:18:11 +0100 From: Al Viro To: NeilBrown Cc: Linus Torvalds , Andreas Dilger , Dave Chinner , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150516141811.GT7232@ZenIV.linux.org.uk> References: <20150514033040.GF7232@ZenIV.linux.org.uk> <20150514112304.GT15721@dastard> <20150516093022.51e1464e@notabene.brown> <20150516112503.2f970573@notabene.brown> <20150516014718.GO7232@ZenIV.linux.org.uk> <20150516144527.20b89194@notabene.brown> <20150516054626.GS7232@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150516054626.GS7232@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1870 Lines: 34 On Sat, May 16, 2015 at 06:46:26AM +0100, Al Viro wrote: > Dealing with multi-component lookups isn't impossible and might be a good > idea, but only if all intermediates are populated. What information does > NFSv4 multi-component lookup give you? 9p one gives an array of FIDs, > one per component, and that is best used as multi-component revalidate > on hot dcache... Having reread the RFC... What's the problem with intermediates? Just put GETFH and GETATTR between the LOOKUP for each component in the same compound and be done with that - you've got yourself everything you might possibly need for populating them. Confused... BTW, I would still very much prefer to allocate a chain of dentries in fs/namei.c (yes, marking them "in-lookup"), then gave an array of pointers (or beginning and end of the chain, but that can be more delicate due to dentry tree topology changes from e.g. d_materialize_unique(), aka d_splice_alias() these days). With the requirement being "populate them in root-to-leaves order, do nothing for ones that had in-lookup flag already cleared". Another fun possibility (but that would take somewhat more restructuring in fs/namei.c) would be to have (on hot cache) a path traced for several components, seeing that they are all on the same fs and delaying revalidation for a while. With bulk revalidate covering all the chain when we stumble across .., mountpoint or something we believe to be a symlink, or when the chain reaches fs-specified limit. Said bulk revalidate should tell how long a prefix had been OK. Permission change handling would be the painful part here... -- 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/