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

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 19, 2006, 20:18 UTC
Message-ID: <Pine.LNX.4.64.0611191156520.3692@woody.osdl.org>
In-Reply-To: <e5bfff550611191107o63d89d8bp5ff4080803a0d784@mail.gmail.com>

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).

Show 5 quoted lines

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