On Wed, Apr 18, 2007 at 10:48:16AM -0400, pryzbyj wrote: > On Wed, Apr 18, 2007 at 10:42:23AM -0400, pryzbyj wrote: > > Hi Jeroen, > > > > Can you still reproduce this bug? Nevermind me, I can reproduce it now.
> > cp -la takes big amounts of memory > > http://bugs.debian.org/412688 > > > > Is this directory tree deeply nested or something? This seems to be the key. > > What filesystem? I reproduced it on ext3 but it seems unlikely that this is relevant (it really shouldn't matter). > > I've set up a test dir with a million (empty) files and after copying > > 340k files see only a small variation in size of the process' memory > > space (it increased by ~500k then shrank and has now increased again). > > Can you [ls]trace the process and see if there's something unexpected > > happening? It just runs link() and lstat(), with the occasional brk(). > One more question. Is the memory usage monotonic over time (perhaps > indicitive of a leak) or does it go down (by how much?)? AFAICT it's monotonically increasing at >100k/s, and I can confirm that this is moderately irritating.. I wonder if this is actually a bug in cp or if it's a glibc problem (related to directory walking?)? Conceivably glibc tries to cache things but never frees the mem. Conceivably it is even working as expected, but happens to give particularly poor performance for cp -al. [EMAIL PROTECTED]:~$ nice ltrace cp -al cpt{,.bak} 2>&1 |head -10000 |sed -e 's/(.*//' |sort |uniq -c |sort -n |tail 2 __errno_location 2 __xstat64 2 mempcpy 3 __lxstat64 3 getopt_long 5 realloc 7 malloc 3320 memcpy 3320 readdir64 3325 strlen Hmm. Briefly inspecing the source seems to indicate that cp *is* trying to do something smart, in particular to warn if I type eg: cp -la foo ./foo baz (since this will copy foo twice). It isn't immediately clear to me if this can be disabled for some cases like cp -l with exactly two non-option arguments. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
