Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753891AbbDXCiU (ORCPT ); Thu, 23 Apr 2015 22:38:20 -0400 Received: from mga02.intel.com ([134.134.136.20]:53699 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750704AbbDXCiR convert rfc822-to-8bit (ORCPT ); Thu, 23 Apr 2015 22:38:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,636,1422950400"; d="scan'208";a="718452904" From: "Drokin, Oleg" To: Christoph Hellwig CC: Boqun Feng , "" , "" , "" , Al Viro , "Dilger, Andreas" , Greg Kroah-Hartman , Jan Kara Subject: Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname' Thread-Topic: [PATCH 1/2] vfs: export symbol 'getname' and 'putname' Thread-Index: AQHQfK+QTxCXxEubcUGDCCSFZfh7bZ1Y/TSA//+VVpeAABGzjYADRyyA Date: Fri, 24 Apr 2015 02:38:15 +0000 Message-ID: <619812A7-B5A5-46AC-B6DA-0F3825B722F9@intel.com> References: <1429674624-25922-1-git-send-email-boqun.feng@gmail.com> <1429674624-25922-2-git-send-email-boqun.feng@gmail.com> <20150422055311.GB3731@infradead.org> <498CF73A-6CB4-4C17-8953-B4AAA855A3DF@intel.com> <20150422063110.GA25768@infradead.org> <83D1849E-D084-4BD6-9A99-720F8F13535A@intel.com> <20150422073430.GA5305@infradead.org> In-Reply-To: <20150422073430.GA5305@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.74.62] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9FCCBA38E8535645B1A9E054AA230617@intel.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3209 Lines: 55 On Apr 22, 2015, at 3:34 AM, Christoph Hellwig wrote: > On Wed, Apr 22, 2015 at 06:49:08AM +0000, Drokin, Oleg wrote: >> I know this is not going to be a popular opinion with you, but sometimes opening a file >> is just too expensive. 1 RPC roudntrip to open a file and then another one to close it. > Use O_PATH to avoid this. Hm, I guess I can open with O_PATH, but? if (unlikely(f->f_flags & O_PATH)) { f->f_mode = FMODE_PATH; f->f_op = &empty_fops; return 0; } so with such an fd I am never getting into my ioctl handler, you see? Let's suppose I overcome this somehow, still that does not completely solve my problem that has more dimensions. So, imagine I have this huge file tree (common with really big filesystems), and I want to do a one-off find on it for whatever reason. I do not want to pollute my dentry and inode cache with all the extra entries because (I think) I know I will never need them again. So with our broken ioctl from the past that was somewhat easy - I just open a dir, I do getdents, I get a bunch of names and I proceed to call my ioctl on this bunch of names and get all the info I need (one rpc per entry, which is not all that great, but oh well) and my dentry cache is only getting directories, but not the files. Now, if I convert to O_PATH (or to some other single call thing that does not need it, like say getxattr that might work for some subset of intended usage), I get pretty much the same thing, but I also get dcache pollution and in order to guard my dcache, I am getting a bunch of lustre locks (the expensive kind of lustre locks issued by server so that the cache stays coherent cluster wide), even if I somehow do uncached dentries so I can avoid the lock, there would still be that pesky LOOKUP RPC (that I would need to somehow teach to not just do lookup, but to bring me other interesting things, kind of like with open intents). This looks like it's getting out of hand rather fast. Now, I probably can create some sort of an RPC that is "extended getdents with attributes" and so my extended_getdents_rpc would return me the name and a bunch of other data like file striping, stat information and the like. This also saves me some more RPCs, but I imagine if I try to expose that over an ioctl, you would not be very happy with it either and I don't think we have this sort of an extended getdents interface at the kernel too, do we (though I think internally nfs is capable of such a thing)? Do you think any of this makes sense, or do you think I should just convert this ioctl from our broken getname version to something like user_path_at() (an exported symbol) to do the lookup+fetch whatever info I need and immediately unhash the resultant dentry/inode and be done with it (at least then I do not need any tools changes). Do you think there's something else I might be doing, but not yet realizing this? Thanks. Bye, Oleg-- 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/