rwatson at FreeBSD.org
Wed Jan 14 13:50:59 PST 2004
On Wed, 14 Jan 2004, Don Lewis wrote:
> The typical user of something like this would be tar when it is deciding
> what to hardlink together. One could make a case for making a nullfs
> mounted copy match the original (or two separately mounted nullfs copies
> match each other). That would do the "right" think when archiving a
> file tree containing nullfs mount points and untarring into a single
> file system, except that it would confuse the heck out of tar because
> the link counts would be wrong. The VOP would be cheap, too. But what
> about a crypto or compression layer?
> The problem for something like tar is that this mechanism doesn't scale
> well. When creating an archive, tar keeps a database of pathnames of
> files that have more than one link, with the inode number as the key.
> Each time encounters a file with multiple links, it does a lookup in the
> database. If it finds a match, it outputs a record with the pathname it
> found in the database, and if it didn't find a match it adds a new
> record to the database. This can be done with reasonable efficiency in
> userland. If the only way of comparing if two files were the same were
> to use syscalls, it would be terribly slow. Tar would only be able to
> keep a list of the pathnames and would have to iterate through the list
> doing the syscall for each entry in search of a match to the current
> file it was processing. This is an O^2 problem with a syscall in the
> loop. Tar might be able to narrow the search by matching file
> attributes, but it would still be possible to have degenerate cases
> unless the inode number were used as an attribute (which would not work
> if you wanted nullfs copies to match).
My thought was that device id and inode number could act as a hint -- only
instead of assuming (id == id && fsid == fsid) meant a match, you'd then
resolve the match using samefile().
> There are programs that could make use of samefile(), such as cp. It
> would probably want a nullfs copy to match the original.
The stacked file system issue is an interesting one -- I think only the
file system that owns an object can decide if the two are the same. So in
the stacked case, it might be possible to have a model where you actually
call VOP_SAMEFILE() on both vnodes, and if either matches, it's considered
OK. The stacked file system would determine if a vnode was "local" or
"stacked", and then pass the VOP_SAMEFILE() down the stack if it was a
stacked vnoded. Most stacked file systems would probably simply say it
was different, but nullfs might say it was the same...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org Senior Research Scientist, McAfee Research
More information about the freebsd-current