Subject: Re: RelCache (aka ELF prebinding) news
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Jason R Thorpe <email@example.com>
Date: 12/03/2002 10:19:06
On Tue, Dec 03, 2002 at 12:14:19PM -0500, Thor Lancelot Simon wrote:
> You should use the length and the filename, no matter what. I'd call
> that "metadata", but maybe you wouldn't. :-) You don't need to include
> them in the checksum, just use them as separate data to match the cache
> entry against. That is basically without cost and makes a collision
> even less likely, as collisions against data of different lengths are
> excluded. And you can still move the file around and not rebind so
> long as you move it back.
Actually, checksumming a library feels ... Wrong to me.
I mean, you're going to have to read in the entire shlib, polluting
the page cache with data you might not even use.
I think that simply matching:
* file name (full pathname)
* file size
* inode number
...is sufficient. Note the last 3 items are available in a single stat(2)
call. I think full pathname is better than file system ID because I'm not
really sure how FS ID depends on order in which the file systems are mounted
and how it might interact with e.g. NFS.
> Other system-wide prebinding schemes seem to also use the modification
> time of the file, and SGI's appears to use the inode number. Thus the
> other schemes require rebinding if you move your shared libraries around.
> I suppose from one point of view, it is an advantage of your system that it
> doesn't do that, though in practice I think it's likely that if you move
> your libraries, you will need to rebind...
Also, moving libraries around is NOT a common practice. I mean, how many
people *really* do that? I certainly have never once moved a shlib around
in the past 4 or 5 years. And, if you move a file within the file system,
it retains its inode number...
> Using the mtime but not the inum would let you not rebind after a
> backup/restore, even.
I think after a backup/restore, you want to re-prebind, just for safety's
sake. A restore is also not a very common operation.
-- Jason R. Thorpe <firstname.lastname@example.org>