From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>, linux-kernel@vger.kernel.org
Subject: Re: Sudden "hangs"....
Date: Sat, 18 Sep 2010 11:04:28 +0200 [thread overview]
Message-ID: <20100918090427.GJ31391@bitwizard.nl> (raw)
In-Reply-To: <20100917164723.GA13770@animx.eu.org>
On Fri, Sep 17, 2010 at 12:47:23PM -0400, Wakko Warner wrote:
> Rogier Wolff wrote:
> > It seems my home workstation hangs on a "mkdir" once every morning for
> > about half a minute. It'll freeze whatever I'm doing and continue
> > happily 30 seconds later, but I can't figure out what's going on
> > because it's frozen...
>
> One of my volumes was doing this. As someone mentioned earlier, check your
> kernel log to see if you have a disk error.
I work at "harddisk-recovery.nl". I know how to recognize bad disks. You can
recognize a bad block in the vmstat output in that the bi and bo numbers
go to zero for at least 10 seconds. This doesn't happen, as you can see
in the original post.
> On mine, I had no errors. The activity led for that volume would be
> on solid until the mkdir completed.
Besides that I can't see the activity led from my chair. But vmstat shows
that it would be solid indeed.
> My fix was to create a new
> directory and move everything over and remove the old directory.
> Obviously this won't work if you're having problems with more than 1
> directory or the offending directory is the root of the volume.
This helps for the "very big directory" case. Directories are never
shrunk. So if a directory has become very large because of thousands
of files at one point in time, you can reduce that with the move-all-files
trick.
When it happened and I recognized the effect, I typed the "time mkdir"
command. I just chose the root of the partition for this. The directory
there is NOT large:
drwxrwsr-x 32 root hdr 4096 2010-09-17 22:05 .
In fact it is as small as possible.
IMHO, the hint is that the flush process for the device ends up in
top. Now if I understand the word "flush" correctly I'd expect it to
write dirty buffers to the device. In this case, vmstat however
reports mostly data coming INTO the computer. So why would the flush
process need to READ data from the device?
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
prev parent reply other threads:[~2010-09-18 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-16 14:33 Sudden "hangs" Rogier Wolff
2010-09-16 23:56 ` Satoru Takeuchi
2010-09-17 16:47 ` Wakko Warner
2010-09-18 9:04 ` 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=20100918090427.GJ31391@bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--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