> > Certainly, but tar isn't going to remember all the inode numbers.
> > Even if you solve the storage requirements (not impossible) it would
> > have to do (4e9^2)/2=8e18 comparisons, which computers don't have
> > enough CPU power just yet.
>
> It is remembering all inode numbers with nlink > 1 and many other tools
> are remembering all directory inode numbers (see my other post on this
> topic).
Don't you mean they are remembering all the inode numbers of the
directories _above_ the one they are currently working on? I'm quite
sure they aren't remembering all the directories they have processed.
> It of course doesn't compare each number with all others, it is
> using hashing.
Yes, I didn't think of that.
> > It doesn't matter if there are collisions within the filesystem, as
> > long as there are no collisions between the set of files an
> > application is working on at the same time.
>
> --- that are all files in case of backup.
No, it's usually working with a _single_ file at a time. It will
remember inode numbers of files with nlink > 1, but it won't remember
all the other inode numbers.
You could have a filesystem with 4billion files, each one having two
links. Not a likely scenario though.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
