public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
Subject: Re: long hangs when deleting large directories (3.0-rc3)
Date: Mon, 20 Jun 2011 23:16:07 +0200	[thread overview]
Message-ID: <20110620211607.GA1722@x4.trippels.de> (raw)
In-Reply-To: <20110620123132.GA1717@x4.trippels.de>

On 2011.06.20 at 14:31 +0200, Markus Trippelsdorf wrote:
> On 2011.06.20 at 13:45 +0200, Michael Monnerie wrote:
> > On Montag, 20. Juni 2011 Markus Trippelsdorf wrote:
> > > Here are two more examples. The time when the hang occurs is marked
> > 
> > Could it be that some sectors on the disk are not easy to read for the 
> > drive, and that it simply retries several times until it works again? 
> > SATA disks can show that behaviour. You could try with "dd" with 
> > seek/skip parameters so you read 1gb at once, then skip 1gb and read 1gb 
> > again etc, and compare the throughput over all 1gb areas. If there's one 
> > slower, that might be the problem.
> > 
> > Maybe a check with "smartctl" could help, too.
> 
> Thanks for the hint, Michael. I've just checked the SMART status on
> both disks and the 4kb drive looks indeed suspicious:
> 
> 197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
> 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
> 
> The 512 byte drive appears to be fine. But I'm running the long
> SMART self test on both of them right now and will report back
> the result in a few hours.

Hmm, both tests ran fine without any errors. And the two SMART
attributes above are back to zero again (must have been a temporary
firmware hiccup). 

As you can see in the data I've posted, the disk workload consists
almost only of writes. And I don't think a disk retries writes several
times. On the contrary a write to a bad sector should fix it, because
the drive can then remap it safely. (Current_Pending_Sector would
decrease and Reallocated_Sector_Ct would increase. But
Reallocated_Sector_Ct is still 0 on both affected drives)

And shouldn't I see these "hangs" in situations other than "rm -fr", if
the disk drive would be responsible?

-- 
Markus

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-06-20 21:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-18 14:19 long hangs when deleting large directories (3.0-rc3) Markus Trippelsdorf
2011-06-18 14:24 ` Christoph Hellwig
2011-06-18 14:37   ` Markus Trippelsdorf
2011-06-19  8:16     ` Markus Trippelsdorf
2011-06-19 22:24 ` Dave Chinner
2011-06-20  0:54   ` Markus Trippelsdorf
2011-06-20  1:34     ` Dave Chinner
2011-06-20  2:02       ` Markus Trippelsdorf
2011-06-20  2:36         ` Dave Chinner
2011-06-20  6:03           ` Markus Trippelsdorf
2011-06-20 11:13             ` Markus Trippelsdorf
2011-06-20 11:45               ` Michael Monnerie
2011-06-20 12:31                 ` Markus Trippelsdorf
2011-06-20 21:16                   ` Markus Trippelsdorf [this message]
2011-06-21  4:25               ` Dave Chinner
2011-06-21  8:02                 ` Markus Trippelsdorf
2011-06-21 18:24                   ` Markus Trippelsdorf
2011-06-21 18:57                     ` Markus Trippelsdorf
2011-06-21 21:22                       ` Markus Trippelsdorf
2011-06-22  0:04                       ` Dave Chinner
2011-06-22  7:06                         ` Markus Trippelsdorf
2011-06-22  7:30                           ` Dave Chinner
2011-06-22  7:40                             ` Markus Trippelsdorf
2011-06-29  4:31                             ` Dave Chinner
2011-06-29  6:19                               ` Markus Trippelsdorf
2011-06-29  7:24                                 ` Dave Chinner
2011-06-29  7:41                                   ` Markus Trippelsdorf
2011-06-29 12:10                                     ` Dave Chinner
2011-06-29 12:48                                       ` Markus Trippelsdorf
2011-06-29 15:08                                         ` Michael Weissenbacher
2011-06-29 23:53                                         ` Dave Chinner
2011-06-21 10:18                 ` Markus Trippelsdorf
2011-06-21 10:40                   ` Markus Trippelsdorf

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=20110620211607.GA1722@x4.trippels.de \
    --to=markus@trippelsdorf.de \
    --cc=michael.monnerie@is.it-management.at \
    --cc=xfs@oss.sgi.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