git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Marco Costalba <mcostalba@gmail.com>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [WISH] Store also tag dereferences in packed-refs
Date: Sun, 19 Nov 2006 12:18:30 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0611191156520.3692@woody.osdl.org> (raw)
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).

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


  parent reply	other threads:[~2006-11-19 20:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-18  9:15 [WISH] Store also tag dereferences in packed-refs Marco Costalba
2006-11-18 18:38 ` Junio C Hamano
2006-11-18 18:43   ` Petr Baudis
2006-11-18 18:47     ` Marco Costalba
2006-11-18 19:04       ` Junio C Hamano
2006-11-19  0:28         ` Marco Costalba
2006-11-19  1:11           ` Linus Torvalds
2006-11-19  1:40             ` Junio C Hamano
2006-11-19  1:45               ` Junio C Hamano
2006-11-19  1:59                 ` Linus Torvalds
2006-11-19  9:40             ` Marco Costalba
2006-11-19 18:05               ` Linus Torvalds
2006-11-19 19:07                 ` Marco Costalba
2006-11-19 20:09                   ` Marco Costalba
2006-11-19 20:36                     ` Linus Torvalds
2006-11-19 20:44                       ` Linus Torvalds
2006-11-19 21:01                       ` Junio C Hamano
2006-11-19 21:14                         ` Linus Torvalds
2006-11-19 21:24                           ` Jakub Narebski
2006-11-19 23:36                             ` Linus Torvalds
2006-11-20  2:35                               ` Junio C Hamano
2006-11-20  9:40                                 ` Jakub Narebski
2006-11-20 12:56                                   ` Marco Costalba
2006-11-20 16:29                                 ` Linus Torvalds
2006-11-20 19:32                                   ` Junio C Hamano
2006-11-19 22:25                       ` Marco Costalba
2006-11-19 23:26                         ` Linus Torvalds
2006-11-19 20:18                   ` Linus Torvalds [this message]
     [not found] ` <200611201154.08732.jnareb@gmail.com>
     [not found]   ` <7vu00u2wln.fsf@assigned-by-dhcp.cox.net>
2006-11-20 11:33     ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0611191156520.3692@woody.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=mcostalba@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).