[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1H1qtW-0001yH-00@dorka.pomaz.szeredi.hu>
Date: Tue, 02 Jan 2007 22:10:02 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: mikulas@...ax.karlin.mff.cuni.cz
CC: pavel@....cz, bhalevy@...asas.com, arjan@...radead.org,
jaharkes@...cmu.edu, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, nfsv4@...f.org
Subject: Re: Finding hardlinks
> > 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists