From: "Theodore Ts'o" <tytso@mit.edu>
To: Kai Tomerius <kai@tomerius.de>
Cc: "Alan C. Assis" <acassis@gmail.com>,
"Bjørn Forsman" <bjorn.forsman@gmail.com>,
linux-embedded@vger.kernel.org,
"Ext4 Developers List" <linux-ext4@vger.kernel.org>,
dm-devel@redhat.com
Subject: Re: File system robustness
Date: Thu, 20 Jul 2023 00:41:20 -0400 [thread overview]
Message-ID: <20230720044120.GB5764@mit.edu> (raw)
In-Reply-To: <20230719105138.GA19936@tomerius.de>
On Wed, Jul 19, 2023 at 12:51:39PM +0200, Kai Tomerius wrote:
> > In answer to Kai's original question, the setup that was described
> > should be fine --- assuming high quality hardware.
>
> I wonder how to judge that ... it's an eMMC supposedly complying to
> some JEDEC standard, so it *should* be ok.
JEDEC promulgates the eMMC interface specification. That's the
interface used to talk to the device, much like SATA and SCSI and
NVMe. The JEDEC eMMC specification says nothing about the quality of
the implementation of the FTL, or whether it is safe from power drops,
or how many wirte cycles are supported before the eMMC soldered on the
$2000 MCU would expire.
If you're a cell phone manufacturer, the way you judge it is *before*
you buy a few million of the eMMC devices, you subject the samples to
a huge amount of power drops and other torture tests (including
verifying the claimed number of write cycles in spec sheet), before
the device is qualified for use in your product.
> But on another aspect: how about the interaction between dm-integrity
> and ext4? Sure, they each have their own journal, and they're
> independent layers. Is there anything that could go wrong, say a block
> that can't be recovered in the dm-integrity layer, causing ext4 to run
> into trouble, e.g., an I/O error that prevents ext4 from mounting?
>
> I assume tne answer is "No", but can I be sure?
If there are I/O errors, with or without dm-integrity, you can have
problems. dm-integrity will turn bit-flips into hard I/O errors, but
a bit-flip might cause silent file system cocrruption (at least at
first), such that when you finally notice that there's a problem,
several days or weeks or months may have passed, the data loss might
be far worse. So turning an innocous bit flip into a hard I/O error
can be a feature, assuming that you've allowed for it in your system
architecture.
If you assume that the hardware doesn't introduce I/O errors or bit
flips, and if you assume you don't have any attackers trying to
corrupt the block device with bit flips, then sure, nothing will go
wrong. You can buy perfect hardware from the same supply store where
high school physics teachers buy frictionless pulleys and massless
ropes. :-)
Cheers,
- Ted
prev parent reply other threads:[~2023-07-20 4:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230717075035.GA9549@tomerius.de>
2023-07-17 9:08 ` File system robustness Geert Uytterhoeven
[not found] ` <CAG4Y6eTU=WsTaSowjkKT-snuvZwqWqnH3cdgGoCkToH02qEkgg@mail.gmail.com>
[not found] ` <20230718053017.GB6042@tomerius.de>
2023-07-18 12:56 ` Alan C. Assis
[not found] ` <CAEYzJUGC8Yj1dQGsLADT+pB-mkac0TAC-typAORtX7SQ1kVt+g@mail.gmail.com>
2023-07-18 13:04 ` Alan C. Assis
2023-07-18 14:47 ` Chris
2023-07-18 21:32 ` Theodore Ts'o
2023-07-19 6:22 ` Martin Steigerwald
2023-07-20 4:20 ` Theodore Ts'o
2023-07-20 7:55 ` Nobarrier mount option (was: Re: File system robustness) Martin Steigerwald
2023-07-21 13:35 ` Theodore Ts'o
2023-07-21 14:51 ` Martin Steigerwald
2023-07-19 10:51 ` File system robustness Kai Tomerius
2023-07-20 4:41 ` Theodore Ts'o [this message]
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=20230720044120.GB5764@mit.edu \
--to=tytso@mit.edu \
--cc=acassis@gmail.com \
--cc=bjorn.forsman@gmail.com \
--cc=dm-devel@redhat.com \
--cc=kai@tomerius.de \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-ext4@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).