From: Mikael Andersson <mikael@karett.se>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Update: Disk io deadlocks during large-file io
Date: Wed, 27 Apr 2005 01:18:48 +0200 [thread overview]
Message-ID: <426ECC58.2070105@karett.se> (raw)
In-Reply-To: <20050426185741.GK7859@marowsky-bree.de>
Lars Marowsky-Bree wrote:
>On 2005-04-26T19:13:31, Mikael Andersson <mikael@karett.se> wrote:
>
>
>
>>With md raid1 instead of dm-mirror i get no lockups during similar
>>workloads or any other workload i've managed to produce. Everything is
>>the same except that i'm using md instead of dm-mirror.
>>
>>
>
>That's not very surprising. md is still the preferred framework for
>raidN as of now, and I'm not sure that will change soon.
>
>
I agree that it's not surprising that experimental ( as it is ) software
fails, and even less that it contains some subtle deadlock cases.
>(Yes, consolidating the stack and everything would be nice, but I don't
>see anyone with time on his hands to go do it ;-)
>
>
Narrowing it down with something to do dm-mirror/dm-raid1 and not driver
or fs related took me some time, quite some time to be honest. So
obviously i've got some amount of time available. The most peculiar
thing was that a new bios for the motherboard actualy changed the
problem characteristic, so i was a bit surprised when it went away
completely as soon as i switched to md.
Doesn't md and dm-raid share the same blocklayer ?
Why does the crashdumps looks so weird, they seem to be waiting for
something in a function which AFAICT from the source and it's
corresponding assembler doesn't wait for anything, at least not in the
stack frame that's indicated ?
Maybe it's just the symbols thats messed up on x86_64 in some way or
i'm just misinterpreting things, i ran gdb vmlinux and looked at it all
from there and comparing it to the output from sysrq-T and addr2line.
According to ps -o cmd,wchan the problematic processes were waiting in
sync_page, or sync_buff according to some notes i have, if that makes sense.
I'll setup a mirror when i've migrated all important data away from
another pair of disks i have and test if i can provoke the problem on
those disks also, that'll give me something to work with.
>Sincerely,
> Lars Marowsky-Brée <lmb@suse.de>
>
>
/Mikael Andersson
prev parent reply other threads:[~2005-04-26 23:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-21 18:37 Disk io deadlocks during large-file io Mikael Andersson
2005-04-26 17:13 ` Update: " Mikael Andersson
2005-04-26 18:57 ` Lars Marowsky-Bree
2005-04-26 23:18 ` Mikael Andersson [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=426ECC58.2070105@karett.se \
--to=mikael@karett.se \
--cc=dm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.