public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: Wols Lists <antlists@youngman.org.uk>
To: Mukund Sivaraman <muks@mukund.org>, linux-raid@vger.kernel.org
Subject: Re: RAID-6 and write hole with write-intent bitmap
Date: Tue, 24 Nov 2020 10:10:32 +0000	[thread overview]
Message-ID: <5FBCDC18.9050809@youngman.org.uk> (raw)
In-Reply-To: <20201124072039.GA381531@jurassic.vpn.mukund.org>

On 24/11/20 07:20, Mukund Sivaraman wrote:
> Hi all
> 
> I am trying to setup a MD RAID-6 array and use the ext4 filesystem in
> ordered mode (default) on it. The data gets backed up periodically. I
> want the array to be always available.
> 
> I prefer not using a write-journal if it is sufficient for my usage. I
> want to use the write-intent bitmap only. AIUI the write-hole problem
> occurs when there is a crash or abrupt power off *and* disk failures.

No, I don't think so. I'm not sure, but aiui, there is a critical point
where the data is partially saved to disk, and should a power failure
occur at that precise point you have a stripe incompletely saved, and
therefore corrupt. This is why you need a log to fix it ...
> 
> * After a crash or abrupt power off, the write-intent bitmap is used to
>   rewrite parity where necessary. If there is no disk failure during
>   this period, is the RAID-6 array guaranteed to recover without
>   corruption?
> 
>   With RAID-6, will recovery with write-intent bitmap succeed with 1
>   disk failure during the recovery period without a write-journal? i.e.,
>   is there a possibility of write hole with 1 disk failure in a RAID-6
>   array?
> 
> * With RAID-6 with write-intent bitmap in use, ext4 in ordered mode, no
>   disk failures, and abrupt power loss, is there any chance of data loss
>   in files other than those being written to just before the power loss?

Probably. Sod's law, you will have other files on the same stripe and
things could go wrong ... Plus I believe some file systems (including
ext4?) store small files in the directory, not as their own i-node, so
there's a whole bunch of other complications possible, plus if you
corrupt the directory ,,,
> 
> (Apologies if these are silly questions, but I request answers.)
> 
RULE 0: RAID IS NO SUBSTITUTE FOR BACKUPS.

And if you don't want to lose live data as it is being updated, you need
a journal. Run the correct horse for the course :-)

Cheers.
Wol


  reply	other threads:[~2020-11-24 10:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24  7:20 RAID-6 and write hole with write-intent bitmap Mukund Sivaraman
2020-11-24 10:10 ` Wols Lists [this message]
2020-11-24 18:50   ` Mukund Sivaraman
2020-11-24 20:16     ` Piergiorgio Sartor
2020-11-24 21:30     ` antlists
2020-11-28  1:57     ` Nix
2020-11-28  1:51   ` Nix

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=5FBCDC18.9050809@youngman.org.uk \
    --to=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=muks@mukund.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