Subject: Re: funlink() for fun!
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: Greywolf <email@example.com>
Date: 07/14/2003 16:05:43
Thus spake Greg A. Woods ("GAW> ") sometime Today...
GAW> > For your definition that file == inode, fine.
GAW> Thank you, finally. FYI you'll find essentially the same definition in
GAW> all the serious books about Unix internals.
Sorry, I always took "file" to mean "data", as opposed to a hard-line
definition that "file" == "inode".
GAW> > name -> inode. Great. Fine. Whatever. N:1
GAW> > inode -> name. 1:N. Pain in the patella.
GAW> Perhaps you've never done anything even remotely like "find -x
GAW> /mountpoint -inum 12345 -print". You can't have. Otherwise you'd
GAW> probably understand at least some of what I'm talking about. (Yes,
GAW> that's meant entirely as sarcasm.)
Oh, no, not at all. I've NEVER been THAT adventurous. ;)
[I refuse to buy into the premise that I'm as stupid as you seem to think.]
GAW> > As the semantics exist right now, it is not a practical idea.
GAW> It's not impossible, or even necessarily impractical given the lack of
GAW> better alternatives for safe and secure programming in some situtations,
GAW> so, it is still something to think about.
No, it's not impossible, but you must define the level of practicality
you're discussing here.
If you maintain a table of reverse lookups in conjunction with open/rename/
link/unlink/mkdir/rmdir, somewhere, that incurs the overhead of rewriting
the system calls to handle that; if, at any time, that scrambles the API,
it becomes impractical, because things will then not behave as defined.
As it stands, such a rewrite is unlikely.
The other choice is to trudge through every directory on the filesystem
and perform unlink()s (effectively) on them. This is time-consuming;
seeing as system calls which do this sort of thing are not expected to
take quite that long, and that they are expected to lock objects until
they complete, this approach is impractical.
GAW> I do think der Mouse's O_NOACCESS flag (and perhaps my O_MKDIR flag as
GAW> well), along with the extra fchdir() and fstat() calls they require, is
GAW> better than funlink(2) since they have a better chance of completeing
GAW> successfully, even in the normal case, and a potentially much better
GAW> chance of giving useful diagnostics in the failure case and doing so in
GAW> a timely fashion.
Thank you. That's a large part of what was being addressed in the beginning
before we got into the debate that seemed to equivocate to "data == metadata".
GAW> However until you understand what I'm talking about
GAW> you can't even begin to sanely discuss funlink(2) or its alternatives on
GAW> the same level playing field.
It's a real good thing I learned how to play pinball or I'd have a very
hard time keeping track of all the angles you're trying to address things
from. Your playing field seems to tilt as you see fit whenever someone
makes a point of disagreeing with you.
I don't think I was hitting too wide of the mark with the points I had
been making, and I still think that, given the nature of the imbalance
of name-to-inod^H^H^H^Hfile mappings, unlink()/funlink() are not ON the
same playing field in the first place as the other f*() calls and their
corresponding pathname counterparts.
If someone else out there with an educated point of view who knows what
filesystems are all about (and who hasn't tired of this discussion) cares
to venture to differ with my POV and take yours, I'll start looking at it
a little more seriously, but until then, I see this as Yet Another Episode
of "The World According to Greg".
GAW> I.e. unless and until you can understand funlink(2) as I've described
GAW> it, together with all its implications and limitations and possible
GAW> optimisations, you cannot possibly even begin to make any fair or
GAW> reasonable assessment of any of the alternatives to this most obvious
GAW> solution to the underlying problem (i.e. the problem which prompted me
GAW> to open the discussion in the first place).
I'll be sure to let the Great Cosmic Creator that (s)he's being replaced
and that you're taking over. Congratulations on winning the election;
when'd it happen?
NetBSD: Power Your Net.