Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

[Drokin, Oleg]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/