Re: Performance hit: symlinks
on Tue, Feb 18, 2003 at 01:15:17PM -0600, Keith G. Murphy (keithmur@mindspring.com) wrote:
> Karsten M. Self wrote:
> >on Mon, Feb 17, 2003 at 10:18:46AM +0100, Jeff Elkins
> >(jeffelkins@earthlink.net) wrote:
> >
> >>Is there one, or if so is it perceptible? For instance, I compiled kde
> >>and qt to live in /opt. If I moved /opt to /usr/local/kde31 and made /opt
> >>a symlink would this create overhead a human would notice?
> >
> >
> > $ ls -l /lib /usr/lib
> >
> >You'll find that *every* (almost) system library is implemented as a
> >symlink.
> >
> >The reason for this[1] is that creating or modifying a symlink is an
> >atomic operation. Deleting and creating a file is two separate
> >operations. If you're updating the library that's used by the function
> >you're using to update the library, you're sort of stuck.
>
> You really get the best atomicity, when needed, by using this:
>
> ln -sf
>
> Remember that the original symlink must be removed, and if that's done
> in a separate step for libc, or ld-linux, which ln depends on, the
> subsequent ln command, to create the link, won't work!
Right. I think that's part of what I was trying to say....
> There is a discussion about this in 'Running Linux', p. 182 in the
> Second Edition.
> >By using symlinks, filehandle open to the old library will continue
> >to work while they are open.
>
> Are you *sure* this is a reason to use symlinks? I really thought old
> libraries stuck around until all filehandles to them were closed
> anyway.
Come to think of it, I believe you're right. I stuck in my footnote
after writing that bit.
> I thought it was more that you don't want to just start overwriting
> the old library directly, because *new* opens by other programs might
> have a problem until the copy finishes. On the other hand, maybe the
> overwrite would try to do an exclusive lock on the library, and not
> work while the library was open by other programs. I'm not inclined
> to try on my system. :-)
I'm not inclined to try it either -- which doesn't mean I haven't....
I believe the answer is a mix of what you and I've said.
Creating a symlink means that:
- There is an atomic operation.
- Processes accessing the library prior to the operation use (and
keep a filehandle open to) the old link target.
- Processes accessing the library subsequent to the operation use
(and keep a filehandle open to) the new link target.
- Creating the link itself is independent of creation or destruction
of targets. We're not creating a new file, or removing an old
one. We're changing a link reference. This means that...
- There is no tween'n'taint period where the system is in an
indeterminate state between *new* processes using one library and
the other, in which the new library file tain't all there yet.
Result: clean live updates of dynamic libraries.
Still likely butchered....
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Geek for hire: http://kmself.home.netcom.com/resume.html
Reply to: