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
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
