Mark Haney wrote:
tracking a lot of hard links, it might be using a lot of memory -- I'd
think it would have to store the inode number for each multi-linked
file.
I don't know what it does with hard-linked directories (but don't use
hard-linked directories!).
Compare the performance to a "find . -size 1024" >/dev/null
The find is fetching as much inode and name space data but shouldn't be
doing any link work.
I just tried this on the same 3TB volume as the du and I get almost
identical results, ~90 minutes.
On my 250 gig backuppc partition:
# time du -sh .
189G .
real 1190m47.881s
user 2m37.849s
sys 23m20.980s
# time find . |wc -l
21120513
real 84m47.798s
user 1m22.193s
sys 9m56.232s
So I think most of the real time is being spent waiting for disk seeks
to the inodes. Since most of the filenames are hardlinks to older
files, none of the tricks normally used to group inodes allocated within
a directory can work. Most 'normal' accesses to this partition are
fast though. In particular it is backing up 20 other machines and
checking for duplicates of all new files with its scheme of hashing and
looking for an existing file. But, the last time I tried to copy one of
these with tar or dump I gave up when it wasn't finished after 3 days.
--
Les Mikesell
lesmikesell@xxxxxxxxx
