From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from muon.cran.org.uk (muon.bluestop.org [IPv6:2605:7700:0:8:1:0:4a32:3323]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5801981ED1 for ; Wed, 23 Nov 2016 17:03:32 -0800 (PST) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BAB0D2F433; Thu, 24 Nov 2016 01:03:30 +0000 (UTC) Received: from muon.cran.org.uk ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gRS7orMgihTg; Thu, 24 Nov 2016 01:03:30 +0000 (UTC) Received: from My-MBP.int.bluestop.org (c-73-20-20-155.hsd1.ut.comcast.net [73.20.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 24 Nov 2016 01:03:29 +0000 (UTC) To: Laszlo Ersek , Michael Zimmermann References: <2ee033d3-bf24-6710-3f72-14bd0e6dfed9@akeo.ie> <98271ced-83d5-d4e9-6b8d-416265054906@rodsbooks.com> <1bd2e268-9a18-6fc1-419d-e50d0e08f6f1@redhat.com> Cc: Rod Smith , "edk2-devel@lists.01.org" , Marcin Wojtas , Pete Batard From: Rebecca Cran Message-ID: <4ad578ff-529b-a1bd-7211-73515527d81d@bluestop.org> Date: Wed, 23 Nov 2016 18:03:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <1bd2e268-9a18-6fc1-419d-e50d0e08f6f1@redhat.com> Subject: Re: EXT FS support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 01:03:32 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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