All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
To: John Stoffel <john@stoffel.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: I/O errors without erros from underlying device
Date: Mon, 7 Dec 2015 21:46:28 +0100	[thread overview]
Message-ID: <201512072146.28378.a.miskiewicz@gmail.com> (raw)
In-Reply-To: <22117.49283.546268.719858@quad.stoffel.home>

On Monday 07 of December 2015, John Stoffel wrote:
> >>>>> "Arkadiusz" == Arkadiusz Miśkiewicz <arekm@maven.pl> writes:
> Arkadiusz> On Monday 07 of December 2015, John Stoffel wrote:
> 
> Arkadiusz> 4.3.0 kernel, raid6 array:
> >> I think there's a bug in the 4.3.x and 4.4-rc3 and lower with block
> >> merges.  I ran into these over the weekend, where v4.2.6 was stable,
> >> but anything higher would lock up and crash on me.
> 
> Arkadiusz> Well, no crashes here.
> 
> That's good.  It was hard(er) to hit when I wasn't running KVM VMs at
> the same time on the server, and I was running strictly RAID1 disks,
> so it's hard to know.
> 
> >> So first step would be to make sure you get and test v4.4-rc4.
> 
> Arkadiusz> Do you know which commit there?
> 
> Try this, from the master lkml git repository:
> 
>     2873d32ff493ecbfb7d2c7f56812ab941dda42f4

It's merge commit. Don't see any obvious patch in that merge that would help 
my case.


Anyway I would expect my problem to be related to badblock lists which numbers 
are close to dmesg error message: [  848.988518] Buffer I/O error on dev md7, 
logical block 3907148544, async page read

> >> http://sprunge.us/XSWI

But how to repair these if write() also fails and 
http://www.spinics.net/lists/raid/msg49325.html suggests that write should 
"fix" these (by using replacement blocks I guess) ?


 
> Arkadiusz> md7 : active raid6 sdg[10] sdad1[9] sdac1[8] sdag1[7] sdaf1[6]
> 
> >> sdae1[5] sdaj1[4] sdai1[3] sdah1[2] sdn1[1] Arkadiusz>       31255089152
> >> blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
> 
> Arkadiusz> bitmap: 1/30 pages [4KB], 65536KB chunk
> 
> Arkadiusz> array had weird failure where many disks went into failed state
> 
> >> but Arkadiusz> remove && adding these disks "fixed" it (turns out not
> >> really fixed it).
> 
> Arkadiusz> Unfortunately now some reads fail:
> 
> Arkadiusz> pread(4, 0x1483a00, 4096, 16003680464896) = -1 EIO (Input/output
> 
> >> error)
> 
> Arkadiusz> To reproduce used xfs_io
> Arkadiusz> xfs_io -d -c "pread 16003680464896 4096" /dev/md7
> Arkadiusz> pread64: Input/output error
> Arkadiusz> which does pread exactly as shown above.
> 
> Arkadiusz> write also fails for that area:
> Arkadiusz> xfs_io -d -c "pwrite 16003680464896 4096" /dev/md7
> Arkadiusz> pwrite64: Input/output error
> 
> Arkadiusz> Note that nothing is written in dmesg when that happens.
> 
> Arkadiusz> I've tried various offsets and sizes of pread and at some point
> 
> >> that was logged: Arkadiusz> [  848.988518] Buffer I/O error on dev md7,
> >> logical block 3907148544, async page read
> 
> Arkadiusz> but no error from underlying devices.
> 
> Arkadiusz> List of bad blocks:
> Arkadiusz> http://sprunge.us/XSWI
> 
> Arkadiusz> What can I do now?
> 
> Arkadiusz> (loosing data from that few sectors is acceptable if the rest
> 
> >> will be readable)
> 
> Arkadiusz> Thanks,
> Arkadiusz> --
> Arkadiusz> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
> Arkadiusz> --
> Arkadiusz> To unsubscribe from this list: send the line "unsubscribe
> 
> >> linux-raid" in Arkadiusz> the body of a message to
> >> majordomo@vger.kernel.org
> 
> Arkadiusz> More majordomo info at
> 
> >> http://vger.kernel.org/majordomo-info.html
> 
> Arkadiusz> --
> Arkadiusz> Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-12-07 20:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07 16:05 I/O errors without erros from underlying device Arkadiusz Miskiewicz
2015-12-07 16:37 ` John Stoffel
2015-12-07 17:06   ` Arkadiusz Miskiewicz
     [not found]   ` <201512071803.26434.arekm@maven.pl>
2015-12-07 17:23     ` John Stoffel
2015-12-07 20:46       ` Arkadiusz Miskiewicz [this message]
2015-12-08  4:02         ` John Stoffel
2015-12-08 11:05         ` Arkadiusz Miskiewicz
2015-12-21  2:25           ` NeilBrown

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=201512072146.28378.a.miskiewicz@gmail.com \
    --to=a.miskiewicz@gmail.com \
    --cc=arekm@maven.pl \
    --cc=john@stoffel.org \
    --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 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.