From: Kai Tomerius <kai@tomerius.de>
To: Theodore Ts'o <tytso@mit.edu>
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: Wed, 19 Jul 2023 12:51:39 +0200 [thread overview]
Message-ID: <20230719105138.GA19936@tomerius.de> (raw)
In-Reply-To: <20230718213212.GE3842864@mit.edu>
> 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.
> ... if power is cut suddenly, the data used by the Flash
> Translation Layer can be corrupted, in which case data written months
> or years ago (not just recent data) could be lost.
At least I haven't observed anything like that up to now.
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?
Thx
regards
Kai
next prev parent reply other threads:[~2023-07-19 10:51 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 ` Kai Tomerius [this message]
2023-07-20 4:41 ` File system robustness Theodore Ts'o
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=20230719105138.GA19936@tomerius.de \
--to=kai@tomerius.de \
--cc=acassis@gmail.com \
--cc=bjorn.forsman@gmail.com \
--cc=dm-devel@redhat.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).