From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?
Date: Sat, 12 Aug 2017 13:51:46 +0200 [thread overview]
Message-ID: <1502538706.3996.1.camel@scientia.net> (raw)
In-Reply-To: <20170812074248.GA3352@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On Sat, 2017-08-12 at 00:42 -0700, Christoph Hellwig wrote:
> And how are you going to write your data and checksum atomically when
> doing in-place updates?
Maybe I misunderstand something, but what's the big deal with not doing
it atomically (I assume you mean in terms of actually writing to the
pyhsical medium)? Isn't that anyway already a problem in case of a
crash?
And isn't that the case also with all forms of e.g. software RAID (when
not having a journal)?
And as I've said, what's the worst thing that can happen? Either the
data would not have been completely written - with or without
checksumming. Then what's the difference to try the checksumming (and
do it successfully in all non crash cases)?
My understanding was (but that may be wrong of course, I'm not a
filesystem expert at all), that worst that can happen is that data an
csum aren't *both* fully written (in all possible combinations), so
we'd have four cases in total:
data=good csum=good => fine
data=bad csum=bad => doesn't matter whether csum or not and whether atomic or not
data=bad csum=good => the csum will tell us, that the data is bad
data=
good csum=bad => the only real problem, data would be actually
good, but csum is not
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]
next prev parent reply other threads:[~2017-08-12 11:51 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 8:38 RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut? Brendan Hide
2017-08-02 9:11 ` Wang Shilong
2017-08-03 19:18 ` Chris Murphy
2017-08-02 11:25 ` Austin S. Hemmelgarn
2017-08-02 12:55 ` Lutz Vieweg
2017-08-02 13:47 ` Austin S. Hemmelgarn
2017-08-02 18:44 ` Chris Mason
2017-08-02 22:12 ` Fajar A. Nugraha
2017-08-02 22:22 ` Chris Murphy
2017-08-03 9:59 ` Lutz Vieweg
2017-08-03 18:08 ` waxhead
2017-08-03 18:29 ` Christoph Anton Mitterer
2017-08-03 19:22 ` Austin S. Hemmelgarn
2017-08-03 20:45 ` Brendan Hide
2017-08-03 22:00 ` Chris Murphy
2017-08-04 11:26 ` Austin S. Hemmelgarn
2017-08-03 19:03 ` Austin S. Hemmelgarn
2017-08-04 9:48 ` Duncan
2017-08-16 18:07 ` David Sterba
2017-08-04 14:05 ` Qu Wenruo
2017-08-04 23:55 ` Wang Shilong
2017-08-07 15:27 ` Chris Murphy
2017-08-10 0:35 ` Qu Wenruo
2017-08-12 0:10 ` Christoph Anton Mitterer
2017-08-12 7:42 ` Christoph Hellwig
2017-08-12 11:51 ` Christoph Anton Mitterer [this message]
2017-08-12 12:12 ` Hugo Mills
2017-08-13 14:08 ` Goffredo Baroncelli
2017-08-14 7:08 ` Qu Wenruo
2017-08-14 14:23 ` Goffredo Baroncelli
2017-08-14 19:08 ` Chris Murphy
2017-08-14 20:27 ` Goffredo Baroncelli
2017-08-14 6:36 ` Qu Wenruo
2017-08-14 7:43 ` Paul Jones
2017-08-14 7:46 ` Qu Wenruo
2017-08-14 12:32 ` Christoph Anton Mitterer
2017-08-14 12:58 ` Qu Wenruo
2017-08-14 12:24 ` Christoph Anton Mitterer
2017-08-14 14:23 ` Austin S. Hemmelgarn
2017-08-14 15:13 ` Graham Cobb
2017-08-14 15:53 ` Austin S. Hemmelgarn
2017-08-14 16:42 ` Graham Cobb
2017-08-14 19:54 ` Christoph Anton Mitterer
2017-08-15 11:37 ` Austin S. Hemmelgarn
2017-08-15 14:41 ` Christoph Anton Mitterer
2017-08-15 15:43 ` Austin S. Hemmelgarn
2017-08-16 13:12 ` Chris Mason
2017-08-16 13:31 ` Christoph Anton Mitterer
2017-08-16 13:53 ` Austin S. Hemmelgarn
2017-08-16 14:11 ` Christoph Anton Mitterer
2017-08-16 15:07 ` Austin S. Hemmelgarn
2017-08-16 17:26 ` Peter Grandi
2017-08-16 18:19 ` David Sterba
2017-08-16 16:54 ` Peter Grandi
2017-08-16 13:56 ` Austin S. Hemmelgarn
2017-08-16 14:01 ` Qu Wenruo
2017-08-16 19:52 ` Chris Murphy
2017-08-17 6:25 ` GWB
2017-08-17 11:47 ` Austin S. Hemmelgarn
2017-08-17 19:00 ` Chris Murphy
2017-08-17 20:34 ` GWB
2017-08-16 16:44 ` Peter Grandi
2017-08-14 19:39 ` Christoph Anton Mitterer
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=1502538706.3996.1.camel@scientia.net \
--to=calestyo@scientia.net \
--cc=hch@infradead.org \
--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 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.