Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751589AbbEQEEr (ORCPT ); Sun, 17 May 2015 00:04:47 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:34069 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbbEQEEh (ORCPT ); Sun, 17 May 2015 00:04:37 -0400 MIME-Version: 1.0 In-Reply-To: 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> <20150516141811.GT7232@ZenIV.linux.org.uk> <20150517131203.7342afc8@notabene.brown> Date: Sat, 16 May 2015 21:04:34 -0700 X-Google-Sender-Auth: rPAK1X4VA8YXTezWOrDEQmUnHnI Message-ID: Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks From: Linus Torvalds To: NeilBrown Cc: Al Viro , Andreas Dilger , Dave Chinner , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2420 Lines: 53 On Sat, May 16, 2015 at 8:48 PM, Linus Torvalds wrote: > > Sorry, but that really is how it is. NFS isn't special enough for some > badly designed lookup models to matter one whit. Btw, it's not just about performance, although the whole "we can do cached lookups without ever having to et the filesystem involved" is a big deal. It's about getting fundamental concpets like mount points etc right, it's about all those those things that the filesystem really doesn't know about, and _cannot_ sanely know about. It's now about things like overlayfs etc, all those things. So the filesystem really isn't in control. Never will be. The filesystem is at the mercy of (extended) unix semantics that are bigger than the filesystem. This is true of IO too. The filesystem does have a bit more flexibility, but in the end, you have to do the readpage thing, because it's the only way you'll get mmap. The filesystem isn't really in control there either, there are strict rules for what it has to do in order to have reasonable coherent mmap semantics. So the vfs layer often does have a "library" approach, because filesystems may do things in very different ways. But at the same time, the vfs layer really *is* in control, because it's the vfs layer that enforces certain basic semantics. So the dcache very much isn't just sme "slave cache" that you choose to use and is at the control of the filesystem. Like the page cache, you don't get a choice, because you aren't in charge. When somebody does a lookup of a filename, it is not a "pass this filename to the filesystem". It very much *is* a component-by-component lookup. And in the *vast* majority of the cases, the cached lookup when you don't even get asked is absolutely the right thing to do, and doing anything else wouldn't just be wrong, it would be completely and utterly stupid. And the fact that somebody doesn't understand that, and has designed bad extensions to do multi-component lookup, isn't actually an argument against the dcache. It's just an argument for "people make bad intterfaces because they hack things up and don't understand things". Linus -- 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/