> >> Is there any reason why the superuser shouldn't be able to open by
> >> inode? This seems an obvious idea; perhaps there's also an obvious
> >> argument against it that I'm not seeing...
>
> JL> Is this really necessary?
>
> It might speed up news servers - maybe even a lot.
I believe someone was running such a system with a patched INN quite a
while ago, and they reckoned that it really did make a difference.
Not that it matters, but I like the idea, although I think that it should
have to be turned on by a mount option for safety reasons (think mode 711
directories, &c). (iopen=(yes|no|root) or similar.)
mail servers could benefit from this as well - qmail, at least, uses inode
numbers for messages in its queue, and I suspect that there are quite a
few packages doing similar things.
In the case that iopen() was included, I think that istat() would be
pretty handy, too...
Hey, while we're adding inode-related system calls, flink() and ilink()
might be quite handy, too, (along with a way to find the inode number
of an unlinked but not yet deleted file through /proc).
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/