From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Nikita Danilov <Nikita@Namesys.COM>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
Linux kernel mailing list <linux-kernel@vger.kernel.org>,
Reiserfs mail-list <Reiserfs-List@Namesys.COM>
Subject: Re: ls command is slow..... (reiserfs, VM)?
Date: Mon, 21 Jan 2002 13:26:30 +0100 (MET) [thread overview]
Message-ID: <200201211226.NAA23145@cave.bitwizard.nl> (raw)
In-Reply-To: <15436.4720.895209.146124@laputa.namesys.com> from Nikita Danilov at "Jan 21, 2002 04:06:56 pm"
Nikita Danilov wrote:
> Rogier Wolff writes:
> >
> > Hi,
> >
> > the "ls" command is horribly slow on my system....
> >
> > I'm doing some stuff with large files. From the old days when files
> > couldn't be larger than 2G, I'm manipulating 1G files.
> >
> > There is currently a program runnning that will make a file sparse if
> > it finds only zeroes in a block. It's reading between 20 and 30Mb per
> > second off the disks, and currently finding only zeros, so there is no
> > writing going on.
>
> Reiserfs puts on-disk inode (stat-data) near file "body" which is an
> array of pointers to actual blocks of the file. This optimizes the case
> of short files, because inode and file "body" can be read in one io. But
> when there are many large files in the same directory, this results in
> inodes of the files from the same directory being far from each other on
> the disk, making readdir() or sequential stat() slower. Reiser4 uses
> (will use, that is) different allocation policy that tries to address
> this.
OK. so the layout on the disk is non-optimal.
But I'd expect performance on the order of:
times
in ms
0 my first stat finishes
0.1 the other program has already issued a 1Mb read from the
other part of the disk.
my ls issues a second stat.
10 seek finishes
18 rotational latency.
58 read (1Mb) finishes (25Mb per second -> 40ms /Mb).
68 seek to "my ls" finishes.
76 rotational latency.
76.1 my stat has transferred its 1k, in the intervening time the
other program has already issued a new read for 1Mb of data.
86 seek to other program's data finishes...
So I'd expect something like 10-14 stats per second. While in fact my
trace showed 3 to 5 stats per second. Still at 50 files in a directory
waiting around 4-5 seconds to see results from an "ls" is kind of
annoyingly slow, and I would've reported it as well.
Maybe the stat requires 2 to 3 IOs to complete? That would explain the
difference.
So the question becomes: Why does a stat require 2 or 3 IOs? OR why is
too much independent stuff scheduled inbetween that one IO takes
200-300 ms?...
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
prev parent reply other threads:[~2002-01-21 12:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-19 16:30 ls command is slow..... (reiserfs, VM)? Rogier Wolff
2002-01-21 13:06 ` Nikita Danilov
2002-01-21 12:26 ` Rogier Wolff [this message]
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=200201211226.NAA23145@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=Nikita@Namesys.COM \
--cc=Reiserfs-List@Namesys.COM \
--cc=linux-kernel@vger.kernel.org \
/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