On Wed 22.Jul'09 at 17:55:51 -0700, Linus Torvalds wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html