Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751258AbbEQXje (ORCPT ); Sun, 17 May 2015 19:39:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58851 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbbEQXjZ (ORCPT ); Sun, 17 May 2015 19:39:25 -0400 Date: Mon, 18 May 2015 09:39:07 +1000 From: NeilBrown To: Al Viro 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: <20150518093907.18330172@notabene.brown> In-Reply-To: <20150517105535.GU7232@ZenIV.linux.org.uk> References: <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> <20150517105535.GU7232@ZenIV.linux.org.uk> X-Mailer: Claws Mail 3.10.1-162-g4d0ed6 (GTK+ 2.24.25; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/xItsA5t4yvqdY=qr=YBZMB0"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3486 Lines: 81 --Sig_/xItsA5t4yvqdY=qr=YBZMB0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 17 May 2015 11:55:35 +0100 Al Viro wrote: > As for Neil's point re do_last() and friends being much too convoluted - = yes, > they are. And it's not a result of trying to shoehorn everything in one > model. "Just let NFS have at it" as soon as we reach do_last() won't make > things any simpler, unfortunately - we'll end up with the same convoluted > mess copied in a bunch of filesystems, each with bugs of its own. There is no reason to be so gloomy. The VFS would provide a generic_do_last() (or whatever) which handles everything correctly for local filesystems which keep the dcache precisely consistent and use it for all the valuable locking it can provide. generic_to_last() would call into other filesystem entry points just like t= he current do_last() does. It wouldn't bother with 'revalidation' though. Then there might be a "generic_network_do_last()" which does minimal if any checking because the server will do all that, and just calls back to the filesystem depending on which particular operation is happening - mkdir, or unlink or whatever. Filesystem developers are both very clever and (I assume) very lazy. If you provide them with tools that work and are easy to understand, they will much rather use them than try to implement their own. This is why the page cache is such a success. The more I think about this, the more it seems to me that having a dentry that can be "unknown", or as you put it "in-lookup" is potentially transformational. Pathname lookup just always returns the dentry of the final component (plus vfsmount), but that final component might be "unknown". Then the various "last" steps are quite separate and each work with this dentry. They unlink or mkdir or mknod or lookup or create or whatever. There are probably races that make this a little more complicated than I am hoping, and rename will doubtlessly be the most interesting. But it feels like a good direction. That is all a long way off of course. Even just getting a "in-lookup" dent= ry and starting to explore what can be done with that would be a very positive step I think. Thanks, NeilBrown --Sig_/xItsA5t4yvqdY=qr=YBZMB0 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIVAwUBVVkmmznsnt1WYoG5AQJ7bQ/6A3XB9HgoYEY8L52s02qaGFMDLGa17zKv HEFUGHmddspCY98DaPLvcGgUfa5GaRVugKT1GUI2wmgEFN5SgrIOZAOFeSxGvLSR 6Wpw6oPS7xgWZ9OJVn14iCg4v5NKAbxdAc8sleArjkGfQ6UthjJUt1ZTO2z6kvFO kBsiRiBH/0bwCuvugfXldovxHORxPK8gGPwelnONOqRJfcXWfT5iqqPNB+uX2mGQ Be3R4TVTvTLPAX/raUZc9UDyY2jbWjb2UZnOsV5HLWXyb9YfTLJ8ZQhiq0h82XJ6 H4prKgbilksuSPGfe44vPayEG8lF8/DQrw0tSRqXkbVdvazI++VMXEvYLlsmQrGU c0g3O5K9Izh9Sb9DgTpJxTb89n0F3PfFH04YGDoq55Ll5wk4B8XKb/XAlUI4+ny+ LhfiPPM9DtKe8tdMTDgZtohTGWcL/EOd6lBN+2OEWbD/d8hcLohZ7iXaNPnISto2 zdD1iRHd7vodRXsWrQ56b9sjX796ABVCZYe88xCJRgO7U8u4Dx2+H1PFKqG7FD8P 0SInbAkQBI5waBH0zk6PdQnBBVjNIY1s8Ri+6JJlt2rtNhqjrqOrTi3MEto06sH9 pVr6GZUv0EAsS1NHufCYGI61orbaoCLV5vxth7VxyDIFK1hx6mAJoPjg2aNgDEmR Wu2GPn+tCEA= =Ofyk -----END PGP SIGNATURE----- --Sig_/xItsA5t4yvqdY=qr=YBZMB0-- -- 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/