linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Jorge Fernandez Monteagudo <jorgefm@cirsa.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs and checksum
Date: Tue, 3 Sep 2019 22:24:25 +0800	[thread overview]
Message-ID: <3930ddc8-f4e9-1db4-dc6a-d8945cda0e10@gmx.com> (raw)
In-Reply-To: <AM6PR10MB3399F9236E61F0AB7CAF4BC8A1B90@AM6PR10MB3399.EURPRD10.PROD.OUTLOOK.COM>


[-- Attachment #1.1: Type: text/plain, Size: 2030 bytes --]



On 2019/9/3 下午9:50, Jorge Fernandez Monteagudo wrote:
>  Hi all,
> 
> This is my first message in this list. I'm looking for advice because I have a weird silent data corruption and maybe with btrfs and the checksum capability this could be, at least, notified to the system, and detected using some btrfs-utils tool or dmesg.
> 
> Imagine you have an SSD with an EXT4 partition in READ ONLY mode and inside several files.

RO of the ext4, and still get corruption? Definitely looks like a
hardware problem to me.

> Every file is an ISO filesystem crypted with cryptsetup. Then first, the EXT4 partition in mounted then every file is mounted using losetup and crytpsetup. We have found, sometimes reading a PNG or WAV file from any of the ISO filesystems mounted, we get an error because the data is incorrect. Flushing caches and trying again don't solve the error. Maybe we have a faulty disk controller and changing the filesystem could be useful, or a RAM with some error...

For btrfs, as long as you're using data csum (default), btrfs can detect
such corruption.

For v5.2 kernel, btrfs can even detects some easy to expose memory
corruption.

But please keep in mind that, due to the fact btrfs (at least least
version) is very picky about corrupted on-disk data or memory, if you
find something wrong, you need to check dmesg to see what's going wrong.

Furthermore, if your ssd is not reliable, especially when it lies about
FLUSH/FUA, btrfs can be easier to be corrupted, as btrfs completely
relies on FLUSH/FUA and metadata COW to ensure its safety against
powerloss, it's way easier to get corrupted if FLUSH/FUA is not
implemented corrected.

(On the other hand, btrfs is more robust against data corruption, so as
long as your SSD is OK, you may find a better experience using btrfs)

Thanks,
Qu

> 
> Changing the EXT4 to btrfs is enough to enable the checksum property or we have to change every ISO file to btrfs to enable the checksum?
> 
> Thanks!
> Jorge
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-09-03 14:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 13:50 btrfs and checksum Jorge Fernandez Monteagudo
2019-09-03 14:24 ` Qu Wenruo [this message]
2019-09-04  6:08 Jorge Fernandez Monteagudo
2019-09-04  6:57 ` Qu Wenruo

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=3930ddc8-f4e9-1db4-dc6a-d8945cda0e10@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=jorgefm@cirsa.com \
    --cc=linux-btrfs@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).