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