Re: [WISH] Store also tag dereferences in packed-refs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sun, 19 Nov 2006, Marco Costalba wrote:
> 
> But why my numbers are bad both in git, in Linux and also qgit (not
> posted) local repo? If it is a single case other repos should load
> fast.

Well, it's almost guaranteed to not really be a "single" case.

An inode on disk is usually ~128 bytes or so, which means that you'll be 
able to fit quite a number of inodes in a page-sized allocation of disk 
cache. If _any_ of the sectors was slow to access (because of IO retries, 
disk sector remapping, whatever), all those inodes will be slow to access.

(It might also be a specific area on the disk, or something).

> Its a Thinkpad 2.5 inches HD, 2 years old (IBM/Hitachi Travelstar 40GNX
> family)

That's a 5400rpm disk with an average seektime of 12ms, and full stroke 
typical seek of 23ms.

A "stat64()" will do more than a single IO when it's cold-cache (the 
kernel will have to look up the directory entry and the inode, of course), 
but you _should_ see just a few IO's (2-3), so quite frankly, normally I'd 
expect to see times in the 0.03s - 0.05s range _maximum_. You'd see less 
if even just part of it was cached (which is normal, exactly because 
things like directory entries are contiguous on disk etc).

And that seems to match your other numbers.

The 0.8s number really is an outlier. It sounds like the drive didn't find 
the sector at first, perhaps had to go to its remapping table, seek around 
a bit more, take a break just to calm down, and then perhaps recalibrate 
itself (or write a SMART record entry).

> >  - your disk is failing, and ends up doing error recovery etc.
> 
> No recent errors are reported:
> 
> Stripped from smartctl -a /dev/hda

Ok, I'm not actually all that familiar with all the SMART error codes, but 
it _looks_ healthy. You do have one Spin_Up_Time event (that is 
marked pre-fail), and those two IDNF errors you have:

>  10 51 01 0f 8e a8 e4  Error: IDNF at LBA = 0x04a88e0f = 78155279
>  10 51 01 0f 8e a8 e4  Error: IDNF 1 sectors at LBA = 0x04a88e0f = 78155279

makes me wonder a bit, but for all I know, it's not actually serious. I 
_think_ the IDNF error means that it couldn't find a sector, but..

		Linus
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]