Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423508AbbEOCvK (ORCPT ); Thu, 14 May 2015 22:51:10 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:53809 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423235AbbEOCvH (ORCPT ); Thu, 14 May 2015 22:51:07 -0400 Date: Fri, 15 May 2015 03:51:03 +0100 From: Al Viro To: Linus Torvalds Cc: Jeremy Allison , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig , Neil Brown Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150515025102.GI7232@ZenIV.linux.org.uk> References: <20150513222533.GA24192@ZenIV.linux.org.uk> <20150514033040.GF7232@ZenIV.linux.org.uk> <20150514220932.GC31808@samba2> <20150514233632.GG7232@ZenIV.linux.org.uk> <20150515012645.GH7232@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 1959 Lines: 37 On Thu, May 14, 2015 at 07:18:16PM -0700, Linus Torvalds wrote: > The only difference - EVER - would be if you pass in the ICASE flag. > Nothing I suggested would change semantics without it (the _hash_ > changes, but that doesn't change semantics, it's a purely internal > random number). > > Now, *with* O_ICASE/AT_ICASE, semantics change. Obviously. At that > point the dentry lookup would match case-insensitively. > > For example, let's say that you have a directory where you already > have both "Blah" and "blah", because you created them in a sane > environment. They'll be two different dentries (assuming they are > cached), but they'll have the same dentry hash. > > Now, you open "blah" with O_ICASE, and the end result is that you > would randomly open one or the other (it would be the one you find > first on the hash chain). Tough. Mixing icase and case-insensitive is > by definition going to cause those kinds of issues. With c-i mount, unpacking a tarball with tar(1) will not (silently, at that) create a situaiton when your c-i users will get lookups proceeding into randomly picked variant of directory, with variants differing only in case. It will do the right thing and put the files where they would be expected, giving an expected "it already exists" if you try to create a directory with the name that matches that of existing file, etc. With this, OTOH, you'll have to use specialized tools for creating files in that tree, or risk random lossage, because creating /mnt/foo/bar when /mnt/Foo/Bugger already existed will succeed just fine, leaving one hell of a mess for c-i users. What's the benefit compared to c-i mount? Not hitting filesystem's ->d_hash() and ->d_compare()? -- 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/