From: Rebecca Cran <rebecca@bluestop.org>
To: Laszlo Ersek <lersek@redhat.com>,
Michael Zimmermann <sigmaepsilon92@gmail.com>
Cc: Rod Smith <rodsmith@rodsbooks.com>,
"edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>,
Marcin Wojtas <mw@semihalf.com>, Pete Batard <pete@akeo.ie>
Subject: Re: EXT FS support
Date: Wed, 23 Nov 2016 18:03:28 -0700 [thread overview]
Message-ID: <4ad578ff-529b-a1bd-7211-73515527d81d@bluestop.org> (raw)
In-Reply-To: <1bd2e268-9a18-6fc1-419d-e50d0e08f6f1@redhat.com>
On 11/23/16 1:11 PM, Laszlo Ersek wrote:
>>> Separately, a small note on ext4 (because you mention it above). I seem to recall a filesystem expert colleague of mine advise *against* using journaled filesystems for booting with e.g. grub2. The argument goes (if I recall right), XFS is considered to be in clean state if the data has made it to the final location *or* the persistent journal. When you cleanly unmount (or remount r/o) and shut down, the journal will be flushed to the final location, so a boot loader that doesn't know about the journal will read consistent data. However, if you crash *without* data loss, then part of the data might be in the journal only, and only clients that can read the journal will see consistent data.
>>>
>>>> This might or might not be
>>>> an issue, depending on what the point of the exercise is.
The problem of course is that "reset" (reboot), "reset -s" (shutdown)
etc. don't have any hooks a driver can use to flush data, so there will
sometimes (depending on how long ago data was written) be an unclean
unmount. At least when booting an OS there's an ExitBootServices event
available to make sure any data is flushed before boot services ends.
Though I've seen one person talking about how there at least used to be
a bug that means ExitBootServices isn't/wasn't called for one OS.
--
Rebecca
next prev parent reply other threads:[~2016-11-24 1:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 15:25 EXT FS support Marcin Wojtas
2016-11-22 16:19 ` Pete Batard
2016-11-22 16:41 ` Rebecca Cran
2016-11-22 16:59 ` Michael Zimmermann
2016-11-22 17:16 ` Marcin Wojtas
2016-11-22 18:25 ` Pete Batard
2016-11-22 21:31 ` Rod Smith
2016-11-23 19:50 ` Laszlo Ersek
2016-11-23 20:01 ` Michael Zimmermann
2016-11-23 20:11 ` Laszlo Ersek
2016-11-24 1:03 ` Rebecca Cran [this message]
2016-11-24 8:27 ` Laszlo Ersek
2016-11-28 21:15 ` Carsey, Jaben
2016-11-22 18:18 ` Pete Batard
2016-11-22 16:40 ` Rebecca Cran
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-list 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=4ad578ff-529b-a1bd-7211-73515527d81d@bluestop.org \
--to=devel@edk2.groups.io \
/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