linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Arka Sharma <arka.sw1988@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: mdadm I/O error with Ddf RAID
Date: Mon, 14 Nov 2016 17:00:45 +1100	[thread overview]
Message-ID: <874m3ak3ci.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAPO=kN2QDLEMgo9p9pU3=MeLQ=J6R8eeDL1Pw9m2pHjbVsuFGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

On Fri, Nov 11 2016, Arka Sharma wrote:

> Hi All,
>
> We have developed a RAID creation application which create RAID with
> Ddf RAID metadata. We are using PCIe ssd as physical disks. We are
> writing the anchor, primary, secondary headers, virtual and physical
> records, configuration record and physical disk data. The offsets of
> the headers are updated in the primary, secondary and anchor headers
> correctly. The problem is when we try to boot to Ubuntu server and we
> observe that mdadm is throwing a disk failure error message and from
> block layer we are getting rw=0, want=7, limit=1000215216. We also
> confirmed using there is no I/O error is coming from the PCIe ssd,
> using a logic analyzer. Also the limit value 1000215216 is the
> capacity of the ssd in 512 byte blocks. Any insight will be highly
> appreciated.
>

It looks like mdadm is attempting a 4K read starting at the last sector.

Possibly the ssd's report a physical sector size of 4K.

I don't know how DDF is supposed to work on a device like that.
Should the anchor be at the start of the last 4K block,
or in the last 512byte virtual block?

DDF support in mdadm was written with the assumption of 512 byte blocks.

I'm not at all certain this is the cause of the problem though.

I would suggest starting by finding out which READ request in mdadm is
causing the error.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

  reply	other threads:[~2016-11-14  6:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11  3:45 mdadm I/O error with Ddf RAID Arka Sharma
2016-11-14  6:00 ` NeilBrown [this message]
2016-11-17  5:21   ` Arka Sharma
2016-11-17  5:49     ` NeilBrown
     [not found]       ` <CAPO=kN2NwC1nZKzmWCEzkxN=OZrYOJFOq__pttqfiLWo-4fJSw@mail.gmail.com>
     [not found]         ` <CAPO=kN3pSizni=e3N3zxktSjQWsRL7T_GwZJdUUyKzCjM-0MWw@mail.gmail.com>
2016-11-21 23:54           ` Fwd: " NeilBrown
2016-11-22  9:30             ` Arka Sharma
2016-11-24 11:29               ` Arka Sharma

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=874m3ak3ci.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=arka.sw1988@gmail.com \
    --cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).