Re: [PATCH] btrfs: raid56: Use correct stolen pages to calculate P/Q

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Andrei Borzenkov <arvidjaar@gmail.com>,
	kreijack@inwind.it, Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: raid56: Use correct stolen pages to calculate P/Q
Date: Mon, 28 Nov 2016 05:01:56 +0100	[thread overview]
Message-ID: <1480305716.6254.8.camel@scientia.net> (raw)
In-Reply-To: <bcbc1321-7a82-f13c-ccf6-91821aab2eac@gmail.com>

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

On Mon, 2016-11-28 at 06:53 +0300, Andrei Borzenkov wrote:
> If you allow any write to filesystem before resuming from hibernation
> you risk corrupted filesystem. I strongly believe that "ro" must be
> really read-only

You're aware that "ro" already doesn't mean "no changes to the block
device" on most modern filesystems (including btrfs)?

> - having separate option to control it will require
> update of every tool that generates initramfs and even then you
> cannot
> avoid using older initramfs with newer kernel.

What would the initramfs have to deal with it? Isn't the whole
repairing thing completely transparent (unless perhaps you do some lo-
level forensics or access the fs directly and not throught the
filesystem driver)?

> Safety means exactly opposite for me - do not modify data if
> explicitly
> requested not to do it.

Depends on what you mean by data...
If you mean "the files as exported in the file hierarchy"... then there
won't be any modifications by repair (after all it just repairs and
gives back the correct data or fails)...

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]