public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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