public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Rebecca Cran <rebecca@bluestop.org>,
	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: Thu, 24 Nov 2016 09:27:54 +0100	[thread overview]
Message-ID: <9da9e2ab-847e-3a8e-83d3-f079eaa5998d@redhat.com> (raw)
In-Reply-To: <4ad578ff-529b-a1bd-7211-73515527d81d@bluestop.org>

On 11/24/16 02:03, Rebecca Cran wrote:
> 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.

Related: https://bugzilla.tianocore.org/show_bug.cgi?id=224

> 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.
> 



  reply	other threads:[~2016-11-24  8:27 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
2016-11-24  8:27                     ` Laszlo Ersek [this message]
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=9da9e2ab-847e-3a8e-83d3-f079eaa5998d@redhat.com \
    --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