> On Mon, 4 Jan 1999, Meelis Roos wrote:
>
> > >> 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.
In other words, make all the system calls inode-based except for some kind
of lookup(filename) to get the inode. Implement filename-based
functions in libraries. Has a certain pointy elegance, but
could seriously mess up the transparency of the fs layer, and faces
either major atomicity issues (if lib based) or ugly functionality
duplication in
syscalls (if, as you recommended, new syscalls just added). For example,
copying a directory to a different disk and mounting it under might mess
up poorly-written programs that kept track of the inodes. Ouch! Could be
an administrative nightmare. But the idea is elegent.... Perhaps trouble
could be avoided by purposely messing up all the inode numbers at mount
time (seeded from /dev/random).
David Feuer
dfeuer@his.com
-
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/