Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #107450 > unrolled thread

Mechanics of the Apple File System transition?

Back to article view | Back to comp.sys.mac.system

Contents

  Mechanics of the Apple File System transition? Alan Browne <alan.browne@freelunchvideotron.ca> - 2017-06-05 17:21 -0400
    Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-05 18:01 -0400
    Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-06 12:03 +1200
      Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-06 13:05 +1200
        Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-05 22:14 -0400
          Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-06 14:50 +1200
            Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-05 23:44 -0400
              Re: Mechanics of the Apple File System transition? Barry Margolin <barmar@alum.mit.edu> - 2017-06-07 11:02 -0400
                Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-08 08:29 +1200
        Re: Mechanics of the Apple File System transition? Alan Browne <alan.browne@freelunchvideotron.ca> - 2017-06-06 19:36 -0400
          Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-06 23:40 -0400
            Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-08 08:23 +1200
              Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-08 10:23 -0400
                Re: Mechanics of the Apple File System transition? Jolly Roger <jollyroger@pobox.com> - 2017-06-08 15:56 +0000
                Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-09 09:23 +1200
                  Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-08 21:49 -0400
                    Re: Mechanics of the Apple File System transition? nospam <nospam@nospam.invalid> - 2017-06-09 00:44 -0400
                      Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-09 14:28 -0400
                        Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-09 15:33 -0400
                        Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-10 13:38 +1200
                          Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-09 22:24 -0400
                            Re: Mechanics of the Apple File System transition? Alan Baker <alangbaker@telus.net> - 2017-06-09 19:29 -0700
                            Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-10 15:59 +1200
                      Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-10 15:59 +1200
                        Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-12 23:56 -0400
                  Re: Mechanics of the Apple File System transition? nmassello@yahoo.com (Neill Massello) - 2017-06-09 13:53 -0600
                    Re: Mechanics of the Apple File System transition? Jolly Roger <jollyroger@pobox.com> - 2017-06-09 23:40 +0000
                    Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-10 13:38 +1200
                      Re: Mechanics of the Apple File System transition? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-06-09 22:27 -0400
                        Re: Mechanics of the Apple File System transition? dempson@actrix.gen.nz (David Empson) - 2017-06-10 15:58 +1200
      Re: Mechanics of the Apple File System transition? Alan Browne <alan.browne@freelunchvideotron.ca> - 2017-06-06 19:29 -0400
        Re: Mechanics of the Apple File System transition? Your Name <YourName@YourISP.com> - 2017-06-07 13:02 +1200

Page 2 of 2 — ← Prev page 1 [2]

#107548

On 2017-06-09 21:38, David Empson wrote:

> For an encrypted volume, the first boot stage including the password
> prompt is achieved by doing a partial startup from the recovery
> partition.

Thanks. That would still make the "looks for boot.efi in
/System/Library/Core Services" work (except it would do so in recovery)
(at which point that code can load the decryption and then transfer
control to the system disk.





> Everything else you wrote is wrong because you started from a false
> assumption.

I was asking qiuestions on how it worked.

[toc] | [prev] | [next] | [standalone]

#107550

On 2017-06-09 7:24 PM, JF Mezei wrote:
> On 2017-06-09 21:38, David Empson wrote:
> 
>> For an encrypted volume, the first boot stage including the password
>> prompt is achieved by doing a partial startup from the recovery
>> partition.
> 
> Thanks. That would still make the "looks for boot.efi in
> /System/Library/Core Services" work (except it would do so in recovery)
> (at which point that code can load the decryption and then transfer
> control to the system disk.
> 
> 
> 
> 
> 
>> Everything else you wrote is wrong because you started from a false
>> assumption.
> 
> I was asking qiuestions on how it worked.
> 

You're nitpicking and trying to create problems where none exists.

It's tiresome.

[toc] | [prev] | [next] | [standalone]

#107557

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 2017-06-09 21:38, David Empson wrote:
> 
> > For an encrypted volume, the first boot stage including the password
> > prompt is achieved by doing a partial startup from the recovery
> > partition.
> 
> Thanks. That would still make the "looks for boot.efi in
> /System/Library/Core Services" work (except it would do so in recovery)
> (at which point that code can load the decryption and then transfer
> control to the system disk.

In that specific case, yes.

That is not always the case. As I said in my previous post, an
unencrypted Fusion drive doesn't load a boot.efi file from a standard
HFS+ volume: it has a special boot partition.

> > Everything else you wrote is wrong because you started from a false
> > assumption.
> 
> I was asking qiuestions on how it worked.

There was no question in your post. It was a series of incorrect
statements based on incorrect assumptions.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#107558

nospam <nospam@nospam.invalid> wrote:

> In article <5939febf$0$38679$b1db1813$19ace300@news.astraweb.com>, JF
> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > 
> > > Did you even bother to read the document I linked in my previous post,
> > > but you trimmed from quotes, or the point I explicitly stated in my
> > > subsequent comments?
> > 
> > > "APFS is now supported as a boot volume with full, native EFI support."
> > 
> > That actualy says nothing.
> > 
> > It could mean that EFI will first look in the EFI partition for an EFI
> > program whch, once loaded, will know how to look for OS_X boot file on
> > an APFS volume.
> > 
> > It could mean that Apple will update firmware for all hardware to give
> > the firmware EFI ability to parse through APFS to look for "boot.efi" file
> > 
> > Or it could mean that APFS emulates HFS and places a block number and
> > size of boot file in the same disk block as HFS and EFI only needs to
> > look there to know wher the boot file is.
> > 
> > Which brings my original question of which of the three is the case ?
> 
> this may give you some insight, although i suspect it won't.
> 
> <https://bombich.com/software/updates/ccc-4.1.16-b1.html>
>    •  APFS startup volumes have new, proprietary Recovery, Virtual
>   Memory, and Preboot volumes. Adding support for these new volume
>   types will take a considerable amount of engineering effort, so
>   support for these is not currently available in this release of CCC.
>   CCC can make a backup of your user and system files to an APFS
>   volume, but it will not produce a bootable backup on an APFS
>   destination. Use an HFS+ destination for now if you require a
>   bootable backup.
> 
> <https://bombich.com/blog/2017/06/07/ccc-support-macos-high-sierra-and-a
> pfs>
>   Creating a bootable APFS volume, however, is brand-new territory. The
>   semantics of starting a Mac from an APFS volume are completely
>   different from those of an HFS+ volume. We have established a
>   procedure to create an APFS startup volume, though, and we've even
>   created a proof-of-concept bootable APFS clone. What lies ahead is a
>   massive amount of engineering work to build support for these new
>   procedures into CCC. APFS encryption is also handled quite
>   differently from CoreStorage encryption, so we have a lot of work to
>   do in regard to building in support for automatically unlocking and
>   mounting APFS encrypted backup volumes. We're aiming to offer new
>   functionality for creating APFS bootable (and optionally encrypted)
>   backups by the time Apple ships macOS High Sierra in the Fall.

The video from the APFS session at WWDC 2017 is now available.

https://developer.apple.com/videos/play/wwdc2017/715/

It didn't go into any detail on external Time Machine drives, but did
have a demo on Mobile Time Machine backups, which shows one of the many
improvements possible thanks to APFS (mobile bakcups are APFS snapshots,
take almost no time to create, no longer have any limit on the size of
files backed up, and include the entire volume including the OS, not
just user data).

It also didn't explain much about the boot process, apart from one
tidbit: when booting APFS, the boot driver is loaded from within the
APFS container, and is referenced by the APFS superblock.

Based on the info from the CCC blog, that will be the "Preboot" volume,
and it looks like that along with the Recovery volume are now inside the
APFS container as well. There is also a Virtual Memory volume. I expect
encryption can be managed at the level of the APFS volume rather than
for the entire container.

That will simplify the GUID partition table, since the entire APFS
container (potentially with multiple volumes) is a single entry.

EFI's "full native support" for APFS almost certainly means that Apple
has done or will be doing firmware updates so EFI can understand APFS
enough to pick a container, read the superblock and load the boot driver
from the PreBoot volume.

Another point from the WWDC session: if an existing drive has multiple
HFS+ partitions and they are converted to APFS, they will end up as
separate APFS containers (each potentially containing multiple volumes)
and they cannot share space. To take full advantage of space sharing it
will be necessary to copy files between partitions/containers, delete
the old partition/container, and resize the remaining container to use
the newly available free space.

Not clear to me yet is whether a single APFS container can contain
multiple bootable volumes, but at the moment I'm leaning towards that
being "no". I expect partitioning at the GUID level will still be needed
if you want to be able to boot into different installs of macOS.

Obviously Boot Camp will still be a partition at the GUID level.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#107598

Just for the record, I finally got the asnwer to my question from the
APFS presentation.

The EFI firmware looks at the superblock on a disk for a block number
and size and then loads the data in those blocks and branches to it. It
does not have any understanding of the file system. (aka: it doesn't
find /System/Library/CoreServices/boot.efi, it gets block numbers and
loads data from those blocks and branches to them.  (those blocks happen
to point to the data inside boot.efi)

APFS renamed the "superblock" to something else but is functionally the
same so the boot propcess from the firmware point of view does not change.


Compatibility with virtual machines mentioned.


there will be defragmentation process that runs in background (due to
copy on write philosophy) but only for spinning disks, not SSDs.

I won't respond to this as it will only be insults.

[toc] | [prev] | [next] | [standalone]

#107532

David Empson <dempson@actrix.gen.nz> wrote:

> Did you even bother to read the document I linked in my previous post,
> but you trimmed from quotes, or the point I explicitly stated in my
> subsequent comments?

It's clear to me that Mezei is a troll. He obviously knows enough not to
make the kinds of errors that appear in his posts: confusing
partitioning schemes with file systems, RAID with Fusion, etc. The fact
that he often *repeats* these things, after being corrected in lengthy
threads, is confirmation of the diagnosis. I learn things from your
responses to him; but as for Mezei himself, just tell him that APFS is
RAID 9 From Outer Space. 

[toc] | [prev] | [next] | [standalone]

#107537

On 2017-06-09, Neill Massello <nmassello@yahoo.com> wrote:
> David Empson <dempson@actrix.gen.nz> wrote:
>
>> Did you even bother to read the document I linked in my previous post,
>> but you trimmed from quotes, or the point I explicitly stated in my
>> subsequent comments?
>
> It's clear to me that Mezei is a troll. He obviously knows enough not to
> make the kinds of errors that appear in his posts: confusing
> partitioning schemes with file systems, RAID with Fusion, etc. The fact
> that he often *repeats* these things, after being corrected in lengthy
> threads, is confirmation of the diagnosis. I learn things from your
> responses to him; but as for Mezei himself, just tell him that APFS is
> RAID 9 From Outer Space. 

+1

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#107543

Neill Massello <nmassello@yahoo.com> wrote:

> David Empson <dempson@actrix.gen.nz> wrote:
> 
> > Did you even bother to read the document I linked in my previous post,
> > but you trimmed from quotes, or the point I explicitly stated in my
> > subsequent comments?
> 
> It's clear to me that Mezei is a troll. He obviously knows enough not to
> make the kinds of errors that appear in his posts: confusing
> partitioning schemes with file systems, RAID with Fusion, etc. The fact
> that he often *repeats* these things, after being corrected in lengthy
> threads, is confirmation of the diagnosis. I learn things from your
> responses to him; but as for Mezei himself, just tell him that APFS is
> RAID 9 From Outer Space. 

Hoping that _someone_ benefits is why I bother to reply to JF Mezei's
error-laden posts, so thanks for that feedback. 

Several times I've started writing a reply to one of his posts then
decided it wasn't worth the effort as explaining things to a brick wall
doesn't benefit either of us.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#107549

On 2017-06-09 21:38, David Empson wrote:
>
> Several times I've started writing a reply to one of his posts then
> decided it wasn't worth the effort as explaining things to a brick wall
> doesn't benefit either of us.



I was gonna say thanks and how I do appreciate your posts, but I guess
you woudn't appreciate.


Hopefully someone else can ask the techniucal questions so you can
educate the group and that person won't automatically be accused of
being a troll because one wants to learn how things work.

[toc] | [prev] | [next] | [standalone]

#107556

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 2017-06-09 21:38, David Empson wrote:
> >
> > Several times I've started writing a reply to one of his posts then
> > decided it wasn't worth the effort as explaining things to a brick wall
> > doesn't benefit either of us.
> 
> 
> 
> I was gonna say thanks and how I do appreciate your posts, but I guess
> you woudn't appreciate.

I do appreciate it when you actually do say thanks.

I don't appreciate it when you continue to argue points that I've
already explained you are comletely wrong about, and demonstrate you
haven't actually bothered to read references I've given, hence the brick
wall reference.

I also don't appreciate it when you post statements and then claim later
that they were questions, when they are not written as a question. I
can't tell which bits you think are true, and which bits you are asking
questions about.

> Hopefully someone else can ask the techniucal questions so you can
> educate the group and that person won't automatically be accused of
> being a troll because one wants to learn how things work.


-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#107477

On 2017-06-05 20:03, David Empson wrote:
> Alan Browne <alan.browne@freelunchvideotron.ca> wrote:
>
>> I'm wary of fundamental changes such as the new AFS that is coming.
>>
>> Will files be converted as needed, or in the background?
>
> The file system conversion must be done as a single step, but thanks to
> the flexibility of APFS, it only needs to write new directory structures
> and possibly fiddle with the partitioning, not touch any file content.

Great relief.

>
>> Or as a part of installing prior to booting under the new system?
>
> Someone has leaked to macrumors.com screen shots of installing the first
> developer preview (in comments on the article about the preview). It
> shows a screen during installation asking whether to convert the drive
> to APFS, with the checkbox off in the picture (no idea if that is the
> default, and the details may change by the public release).
>
> On that basis, the conversion will optionally happen as part of
> installing High Sierra. I expect there will be a manual method of
> converting to APFS later, which will probably involve a restart if you
> do it on the startup drive.

I'm all for updating - just worried about impact.

> The keynote said that APFS would be the default for new machines.

Great.

>
>> How about external drives?  Will they need to be re-formatted?
>
> No. I expect there will be an optional "convert to APFS" feature for
> external drives, which will probably involve an unmount, directory
> rewrite, then remount. It might take a while depending on the number of
> files (Time Machine drives especially).

Fine.  Relieved again if it is so.

>
> Obviously you should only do this with external drives that are going to
> be used exclusively with recent macOS versions (10.12 Sierra or later,
> unless Apple ports limited APFS support back to 10.11 El Capitan - at
> the moment El Capitan knows to ignore APFS volumes, but earlier OS X
> versions will offer to initialize the drive as they have no idea what
> the file system is).

I Never look back.

>
> We'll probably know more later in WWDC once they have the APFS session,
> and there may be more info in the "Platform State of the Union" address,
> which I won't have time to watch for the next few hours.

Thanks David - much appreciated.

-- 
"If war is God's way of teaching Americans geography, then
recession is His way of teaching everyone a little economics."
   ..Raj Patel, The Value of Nothing.

[toc] | [prev] | [next] | [standalone]

#107479

On 2017-06-06 23:29:27 +0000, Alan Browne said:
> On 2017-06-05 20:03, David Empson wrote:
>> Alan Browne <alan.browne@freelunchvideotron.ca> wrote:
>>> 
>>> I'm wary of fundamental changes such as the new AFS that is coming.
>>> 
>>> Will files be converted as needed, or in the background?
>> 
>> The file system conversion must be done as a single step, but thanks to
>> the flexibility of APFS, it only needs to write new directory structures
>> and possibly fiddle with the partitioning, not touch any file content.
> 
> Great relief.

As always: MAKE A BACK UP before updating the OS.

Preferably a completely new, separate backup that is then stored away 
safe somewhere until you're positive the new OS is working properly.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.mac.system

csiph-web