Re: Performance issue of 'git branch'

From: Carlos R. Mafra <crmafra2@gmail.com>
Date: Jul 23, 2009, 02:02 UTC
Message-ID: <20090723020238.GA8948@Pilar.aei.mpg.de>
In-Reply-To: <alpine.LFD.2.01.0907221753290.3352@localhost.localdomain>

On Wed 22.Jul'09 at 17:55:51 -0700, Linus Torvalds wrote:

Show 11 quoted lines

> On Wed, 22 Jul 2009, Linus Torvalds wrote:
> > 
> > If you have ext3, you'd do something like
> > 
> > 	tune2fs -O dir_index /dev/<node-of-your-filesystem-goes-here>
> 
> One last email note on this subject. Really. Promise.
> 
> If you do that "tune2fs -O dir_index" thing, it will only take effect for 
> _newly_ created directories. So you'll still need to do that whole 
> "mv+cp+rm" dance, just to make sure that the refs directories are all new.

Ok, now I also did the "dir_index" thing followed by the mv+cp+rm instructions. It doesn't change the 3.5 secs delay in that single line,

1248313742.355195 lstat(".git/refs/heads/sparse", 0x7fff0c663ab0) = -1 ENOENT (No such file or directory) 1248313742.381178 lstat(".git/refs/heads/stern", 0x7fff0c663ab0) = -1 ENOENT (No such file or directory) 1248313745.804637 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0

Just to double check,

[root@Pilar linux-2.6]# tune2fs -l /dev/sda5 |grep dir_index Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

(and I did the mv+cp+rm after setting "dir_index")

Is there another way to check what is going on with that anomalous lstat()? [ perhaps I will try 'perf' after I read how to use it ]

Thanks, Carlos