MacInTouch Amazon link...

APFS / file systems

Channels
Apple, Security, Other, Products
Apologies if this is really basic, but it's perhaps a practical observation and might be of help to others.

Over the years I ripped a very large number of audiobooks using, first, iTunes then Audiobook Builder. Most are in the .m4b audiobook format, others in .mp3

I'm in the process of consolidating backups to a Synology. Last night, I did a test copy of audiobooks ripped on Macs, and a somewhat ambiguous Synology error reported inability to copy some files, which I think were the resource fork files.

Did a search on the backup drive (which is mounted in Linux) and found the Audiobooks folder had something over 32,000 "._" resource fork files at 4.1 KB each, though some were curiously much larger. Having searched them out in Linux, I deleted them, and the audiobook files copied without a Synology error report. Today I did a one-folder test copy of files with the "._" files in place. Synology again rejected the "._" files with an error message, but accepted the actual audio files. They're working fine, so unless you want to "prune" your source drive, there's no reason to search out and delete the "._" files.

This led me to wonder how those Mac resource fork files are handled in APFS. Wish I had an answer, as the only Macs I have with APFS are fresh installs. What I did find is that Mac users who want to archive and access old files can do so, but it may take some preparation. Here's a resource I found.
The House of Moth said:
 


Ric Ford

MacInTouch
What about bootable install media? To my knowledge, bootable installers only work with HFS+.
Apple confirms that
Apple Support said:
How to create a bootable installer for macOS
...
Use the 'createinstallmedia' command in Terminal
  1. After downloading the installer, connect the USB flash drive or other volume you're using for the bootable installer. Make sure that it has at least 12GB of available storage and is formatted as Mac OS Extended.
 


I'm in the process of consolidating backups to a Synology. Last night, I did a test copy of audiobooks ripped on Macs, and a somewhat ambiguous Synology error reported inability to copy some files, which I think were the resource fork
...
Did a search on the backup drive (which is mounted in Linux) and found the Audiobooks folder had something over 32,000 "._" resource fork files at 4.1 KB each, though some were curiously much larger. Having searched them out in Linux, I deleted them, and the audiobook files copied without a Synology error report....
The Linux file systems don’t have resource forks, so the AFP file server stores them in separate files and sends them back to a Mac in the right contextsm if asked for. You have copied the files, but the real test would be to use an application that asked for the fork because it had stuffed something it needed there.

Relatively new apps probably don’t care what is in those forks, so a bit of ‘don’t ask, don’t fail.‘
This led me to wonder how those Mac resource fork files are handled in APFS. Wish I had an answer, as the only Macs I have with APFS are fresh installs.
Even HFS+ had started to move onto file attributes (beyond very basic metadata). Resource forks have been deprecated for an age and a day. APFS mapped over the attributes feature.


For each metadata attribute that the server’s file system doesn’t have, the APF server will need to store those in a file someplace. APFS has even more, which is another reason it isn’t tracked in deprecated AFP.
 


You have copied the files, but the real test would be to use an application that asked for the fork because it had stuffed something it needed there.
Thanks for your insight. I'm not planning on bringing these audiobook files back to iTunes, which would be the scenario where that might matter. It could matter more on data files that wouldn't open, but thus far, nothing I've transferred from Mac to Synology has refused to open.
 


This led me to wonder how those Mac resource fork files are handled in APFS. Wish I had an answer, as the only Macs I have with APFS are fresh installs. What I did find is that Mac users who want to archive and access old files can do so, but it may take some preparation. Here's a resource I found.
Lyman did his usual great job of answering your question, but specifically to the question I've quoted above...

Nearly 15 years ago, Apple introduced Extended Attributes in HFS+ (HFS Extended). These are used to store metadata, which is just descriptive information about a file or folder. Extended Attributes provided a way to store information about a file in addition to what had been only two choices, the two forks, data and resource.

While the on-disk HFS+ implementation maintained extent records for both the data fork and the resource fork, resource forks were converted to Extended Attributes (xattrs), and the process used by developers for creating and using resource forks was eventually completely removed from macOS. Extended Attributes provided better compatibility with other file systems, including network file systems that have the concept of metadata stored as attributes.

Being a modern file system, APFS is also designed to store metadata as Extended Attributes. As an example, the most common xattr is the information used by the Finder for files and folders — for instance, whether a folder has an open window in the Finder, and where on the screen it's located.

A "resource fork" can still be the name of an Extended Attribute in APFS, just as it has been in HFS+ for a long time. If you copy a file from a very, very old set of files that still contain the classic resource fork, from many years ago, to an APFS volume, it will become an Extended Attribute for the copy of the file on the APFS volume.

There's a little bit more to the story, but I've gotten pretty deep already, and this covers the concepts well enough, I believe.
 


Even HFS+ had started to move onto file attributes (beyond very basic metadata). Resource forks have been deprecated for an age and a day. APFS mapped over the attributes feature.
Of possible historical interest, Windows NT's NFTS introduced something like resource forks, in a more generic fashion: alternate data streams. Instead of being highly structured, like the Mac Resource Fork, ADS are a general-purpose tool for developers to use as they wish.

Windows Internet Explorer, as an example, uses ADS to record security zones for its downloads. On the Mac, Safari adds an extended attribute to indicate it was downloaded and from where. On Windows, IE adds an alternate data stream that indicates what security network zone the file came from (e.g., Internet, which is untrusted).

Like the Mac's extended attributes and resource forks, the ADS goes with the file … so long as the transmitting system knows how to deal with it. You can strip the ADS off a Windows file by sending it to a Mac, just like you can strip off EAs and resource forks from Mac files by sending them to Windows.

No platform seems to have a lock on file system quirks — they're all weird when looked at from the other side of the street. :)
 


What about bootable install media? To my knowledge, bootable installers only work with HFS+.
Good point. That's one area where Apple will hold off for just another iteration or two longer. They partially painted themselves into a corner by combining firmware updates with macOS upgrades. So an older system sitting on 10.11 (El Cap) or some early 10.12 (Sierra) or something a bit older is in a 'chicken and egg' situation of moving to macOS 10.15. If the installer is on an APFS volume but [contains an older macOS that] can't read APFS, then you can't run the installer with the firmware upgrade needed to read APFS.

There may be a bit of demographic sampling skew in their data, but Statcounter Globalstats put the pre-macOS 10.13 (High Sierra) group at around 30% share. (Mojave hasn't cracked 50% yet. High Sierra didn't either, until just before the Mojave release.)

Except for the Mac Pro 2009-2012 models, macOS 10.15 is being aimed at the same set of Mac models as macOS 10.14 was. Apple is trying to get the folks on a slow upgrade cadence to move. An installer with an "extra step" is enough for some to use as an excuse to not move. At some point, though, what will be left is the folks who really just don't want to move.
(Is it possible that createinstallmedia recognizes my older hardware and won't allow APFS? Can someone with a new Mac test this?)
Apple probably only wants one active installer OS instance to maintain. I don't have macOS 10.15 Catalina beta. That might be the transition point. In my opinion, it would be a good idea to mandate that folks jump to Mojave before moving on past that. They could stop and get the 32-bit app warnings. Migrate legacy Quicktime formats. There just are several major migration preparation points here. I would try to encourage folks not to make 2 to 3+ jumps in OS versions to 10.15.

Apple's 2019 Macs, though, look much like what should have been 2018 hardware — Intel CPUs on the same microarchitecture, keyboard fixes that should have arrived sooner, etc. So, one more generation with HFS+, but it is probably not going to be a priority when we finally get to something new.

At some point, the installer OS will move to "user data' volume and "system" volume split and will need an APFS container. Apple may have kicked the can further on the 10.15 installer, but after that, it seems pretty likely. (Apple should see a wide variety of systems deploy the new OS structure and be able to get to a stable, scoped-down version of it for the installation OS. )
 


What about bootable install media? To my knowledge, bootable installers only work with HFS+.
The HFS+ requirement for bootable install media is to support installation of newer macOS versions on older Macs that have never heard of APFS.

Since newer Macs can boot from GUID-based HFS+ boot volumes, any good beancounter Tim CEO would insist on providing only one version. Think 'support cost'.
 


On two different external APFS drives, the TechTool Pro Volume Structures test runs normally when there is only one volume in a container. After a second APFS volume is added to the container using Disk Utility, Volume Structures stalls on each volume with the selected volume unmounted and the Freeze Volume light blinking. If the added volume is removed, the test again runs normally on the remaining volume.

My system: 2018 Mac Mini, Mojave 10.14.6, TechTool Pro 11.0.5. One test drive was a USB spinning disk attached directly to the Mac, the other a Thunderbolt SSD attached through an Akitio Thunderdock and Apple Thunderbolt 2 to 3 adapter.

I reported this on the Micromat website on Sept.1, 2019. The official response was to say I was the first to report it and to send email to help@micromat.com, which I did. Then the topic was locked. A canned email response soon followed, but nothing since.

I repartitioned the drives with two volumes in separate containers as a workaround. That worked.

Here's the link to the forum topic:

This is not a complaint, just an FYI.
 


On two different external APFS drives, the TechTool Pro Volume Structures test runs normally when there is only one volume in a container. After a second APFS volume is added to the container using Disk Utility, Volume Structures stalls on each volume with the selected volume unmounted and the Freeze Volume light blinking. If the added volume is removed, the test again runs normally on the remaining volume.
My system: 2018 Mac Mini, Mojave 10.14.6, TechTool Pro 11.0.5. One test drive was a USB spinning disk attached directly to the Mac, the other a Thunderbolt SSD attached through an Akitio Thunderdock and Apple Thunderbolt 2 to 3 adapter.
I reported this on the Micromat website on Sept.1, 2019. The official response was to say I was the first to report it and to send email to help@micromat.com, which I did. Then the topic was locked. A canned email response soon followed, but nothing since.
I repartitioned the drives with two volumes in separate containers as a workaround. That worked.
Here's the link to the forum topic:
This is not a complaint, just an FYI.
After my reply to Lyman T on Aug 21, I went back to test Disk Utility on an external USB SSD drive formatted for APFS. I added a second volume (with a couple of gigs of movies) to the container with the original bootable volume (macOS 10.14.6). I booted from the bootable volume, and ran First Aid from Disk Utility on the added volume.

As I remembered, it locked the boot volume as well as dismounting the new added volume. At the end of the run I got the messages:
File system check exit code is 0.
Restoring the original state found as mounted.
Problem -69842 occurred while restoring the original mount state.
Operation successful.
After pressing the Done button, the boot volume seem to operate normally, but the added volume could not be mounted. After a restart the added volume mounted and seemed normal.

It looks like Apple also has issues with multiple volumes in a single container.
 


After my reply to Lyman T on Aug 21, I went back to test Disk Utility on an external USB SSD drive formatted for APFS. I added a second volume (with a couple of gigs of movies) to the container with the original bootable volume (macOS 10.14.6). I booted from the bootable volume, and ran First Aid from Disk Utility on the added volume.

As I remembered, it locked the boot volume as well as dismounting the new added volume. At the end of the run I got the messages:

After pressing the Done button, the boot volume seem to operate normally, but the added volume could not be mounted. After a restart the added volume mounted and seemed normal.

It looks like Apple also has issues with multiple volumes in a single container.
Oops, I may have had an old firmware on my USB SSD. The firmware I originally had was probably 280.0.0.0.0. Reinstalling macOS 10.14.6 Supplemental Update on the booted SSD, Disk Utility worked successfully with no errors.

Using Howard Oakley's SilentNight v1.2, the present firmware is 220.270.99.0.0, which is apparently the latest firmware.

I also tried the SSD on my 2012 Mini server with macOS 10.14.6, and it worked successfully also. The original runs were on my 2018 Mini.
 



Ric Ford

MacInTouch
APFS vs. hard drives:
Mike Bombich said:
An analysis of APFS enumeration performance on rotational hard drives
My APFS-formatted rotational disks have always felt slower than when they were HFS+ formatted. The speed of copying files to them felt about the same, but slogging through folders in the Finder was taking a lot longer. At first I shrugged it off to the filesystem being new; "It just needs some tuning, it will come along." But that performance hasn't come along, and after running some tests and collecting a lot more data, I'm convinced that Apple made a fundamental design choice in APFS that makes its performance worse than HFS+ on rotational disks. Performance starts out at a significant deficit to HFS+ (OS X Extended) and declines linearly as you add files to the volume.

The rest of this article is fairly technical, here are the key takeaways:
  • Enumerating an APFS filesystem on a traditional hard disk drive (rotational disk) will take 3-20X longer than HFS+ on the same hardware.
  • This performance difference is most noticeable on a macOS startup disk that is (or includes) a rotational disk.
  • If Apple doesn't make some concessions in the APFS filesystem to accommodate the slower seek performance of hard disk drive devices, then a rotational device will never be able to provide acceptable performance as a production macOS startup disk.
 


I could sort of understand this kind of performance issue if Apple was only selling systems with SSDs in them, but it's not true. All of the iMac models ship with either a hard drive or a fusion drive in the base configurations, requiring expensive BTO upgrades to go to SSDs.

It's almost as if they want people to have a miserable experience on what are some of the most expensive mainstream desktop systems sold today. If they believe you should be buying a laptop or a pro system, then they should just admit it and stop selling iMacs.
 


Mike Bombich said:
Enumerating an APFS filesystem on a traditional hard disk drive (rotational disk) will take 3-20X longer than HFS+ on the same hardware.
This analysis is very interesting. The gist is that because APFS stores the file system metadata mixed in with the file data, file seek operations are slow on spinning disk (hard disk drive) drives. This doesn't just affect operations like backups that enumerate the entire file system; it also affects boot time. The recommendation is to only use SSD storage for APFS boot drives.

What he doesn't discuss is whether the Fusion drives are affected. I see some news that APFS stores all the metadata on the SSD component of the Fusion drive, which would indicate that Fusion drives are OK.

So your APFS Mac has an internal SSD or Fusion drive. Are you unaffected? Mike's point is that if your bootable backup clone drive is an hard disk drive, then it is going to be really slow when you need to boot from it, such as when your primary drive fails.

You could get an external SSD but at what cost? A backup drive needs high capacity; at least as large as the Fusion drive you're cloning. What we need is an SSD/hard disk drive combo in an enclosure that could be mounted as an external Fusion drive. Does such a thing even exist?
 



This analysis is very interesting. The gist is that because APFS stores the file system metadata mixed in with the file data, file seek operations are slow on spinning disk (hard disk drive) drives. This doesn't just affect operations like backups that enumerate the entire file system; it also affects boot time. The recommendation is to only use SSD storage for APFS boot drives.
File System information in both HFS and APFS is stored in data structures known as trees. Trees have nodes that contain file information for multiple files. Imagine that the main tree, in either file system, contains 10,000 nodes. In HFS, nodes are generally grouped together adjacently in what are known as extents. For instance, there may be 5,000 nodes all adjacent, one right after the other, in two different extents (sections). So enumeration can move from one disk sector to the next, repeatedly, on a spinning hard drive storage device. With caching, a large section can be read at once, scooping up lots of nodes, and enumeration can occur in RAM. Much faster.

APFS is designed for SSDs, and SSD are designed with wear leveling in mind. Unlike a spinning hard drive, disk sector number 1 and disk sector number 2 may not be anywhere near each other. SSDs "move" sectors around, by renumbering them, to spread out usage over time across the entire device. In APFS, nodes are generally not grouped together, but remain separate. There are no "tree extents" in APFS. Since SSDs renumber sectors in their wear-leveling system, it makes no sense to design adjacent sections, because in reality, they're not adjacent at all. Those 5,000 nodes mentioned above are spread out all over the disk device. For SSDs, that's almost like having them in RAM, so to speak, because SSDs are fast.

Put APFS on an spinning drive, and with those nodes spread all over the drive, there is a lot of slowdown waiting to read nodes — which also makes it difficult to just read a chunk of the disk to scoop up a bunch of nodes for searches and enumerations. APFS also has an extra level of indirection, but that gets very technical, so let's just say there's generally an extra step involved with APFS. Caching, plus storing important parts on the SSD portion of a Fusion drive, can cut down on some of the slowdown of APFS on spinning drives, but it can't make up for everything. There are other factors, like copy-on-write, that can play a part, but again, that can get extremely technical and requires some background knowledge.

I use APFS on all my Macs, and they all have Fusion drives. Since I don't do anything requiring high-end disk performance, I don't notice anything. For video editors, servers, etc., it may be an issue. But we are not too far away, I am guessing, from Macs being shipped with only SSD internal storage. It's certainly the future, and so is APFS.
 


Ric Ford

MacInTouch
I did look through the thread and couldn't really find anything that could help me.
Did you see Brian Lawson's post? That looks like the answer to me (other than Apple cleaning up its "quantum" disk space reporting mess).
When I see the system telling me my boot drive is getting too full (I use TechTool Pro to monitor its usage levels) it has always been due to snapshots filling the drive. I usually see this right after updating the OS. Carbon Copy Cloner has the ability to monitor and manage snapshots so I can delete older or larger snapshots killing my free space.
#appleui
 


Did you see Brian Lawson's post? That looks like the answer to me (other than Apple cleaning up its "quantum" disk space reporting mess).
I did. I looked in Carbon Copy Cloner, and there are indeed snapshots taking up several GB of space (for some reason it is not letting me delete any, so I need to work on that, too). However, it still doesn't explain how I could delete 100 GB of files and have the system report to me that there is now even less free space available. In the words of Bart Simpson, "¡Ay, caramba!"

Sometimes I long for the days of System 9, when I could troubleshoot just about anything.
 


Ric Ford

MacInTouch
I did. I looked in Carbon Copy Cloner, and there are indeed snapshots taking up several GB of space (for some reason it is not letting me delete any, so I need to work on that, too). However, it still doesn't explain how I could delete 100 GB of files and have the system report to me that there is now even less free space available.
I haven't tried this, but you might want to check out DaisyDisk and this post. Let us know if that helps....
 


I did. I looked in Carbon Copy Cloner, and there are indeed snapshots taking up several GB of space (for some reason it is not letting me delete any, so I need to work on that, too). However, it still doesn't explain how I could delete 100 GB of files and have the system report to me that there is now even less free space available. In the words of Bart Simpson, "¡Ay, caramba!"
Sometimes I long for the days of System 9, when I could troubleshoot just about anything.
Okay, I'll enter this fray one more time. I have been struggling with this behavior for a long time. On various forums, after I first pointed it out as a problem of mine, people routinely directed me to pages that described snapshots. Indeed, a big part of this can be snapshot-related. I did all kinds of tests. I discovered that booting from another drive and then checking my free space sometimes showed it accurately. The "get info" windows would function, but CCC would not show free space (FYI - I am a huge fan of CCC and Mike Bombich). It got so bad on my last MacBook Pro, with a 1TB boot drive, that I did the real hassle step of cloning it every few months. This would restore to me an honest amount of free space. That's not ideal. I would then delete a MobileSync archive and lose a bunch of gigabytes, but it would still not reflect. It became a drag to throw things out, as I knew my free space was declining steadily.

When I got the latest MacBook Pro , with a 2TB drive, I decided to turn off Time Machine. That has worked better than anything else to mitigate this issue. On my external backups, I still have free space reporting problems - the APFS-formatted backups, that is - but I wait a lot longer to wipe and redo them than I used to.

I wish I could say I have a definitive answer, but I know for sure I'm not alone with this issue, and that is always reassuring. It's definitely related to APFS, and Time Machine seems to contribute to it. So, yes, it would seem to be snapshot-related, but I don't know if that's 100 percent of it.
 


Any advice on where I need to look for a problem? I have a suspicion that I really have scads more storage space than is indicated.
I recently gained back about 400 GB on my boot drive. One of the main issues was snapshots, which were impervious to deletion. The fix was pretty simple, although it sounds a little extreme: download the macOS 10.14.6 full installer and do an "install in place", which will not harm your configuration at all. It will delete all existing snapshots and leaves the drive(s) in a state where snapshots work as they should. CCC and tmutil afterwards have no problem deleting snapshots, and Time Machine has been handling that as expected. I had rather cavalierly turned on all the snapshot options in CCC - not a great idea. Not that CCC was doing anything "wrong", but you should really think carefully about whether you need to use snapshots or not.

Additionally, I found I had turned on logging in Mail's "Connection Doctor", probably a couple of years ago, to do some troubleshooting. Ouch! I think there was about 50 GB of logs dutifully recorded. These self-inflicted problems are the most painful ones.
 


I haven't tried this, but you might want to check out DaisyDisk and this post. Let us know if that helps....
I downloaded and purchased DaisyDisk. It reports 229.2 GB Free Space and 814.1 GB of Free and Purgeable space. Finder and Disk Utility just show the 229.2 GB. Further inspection shows the purgeable space of 561 GB to be Time Machine temporary backups and system caches. Time Machine is off, so maybe this is detritus from the old computer that this one replaced. I am going to purge those with DaisyDisk and also turn off Snapshots in Carbon Copy Cloner, and that should take care of things nicely.
 


I haven't tried this, but you might want to check out DaisyDisk and this post. Let us know if that helps....
DaisyDisk identified a bunch of Time Machine snapshots and system caches taking up half a terabyte of space. Time Machine is off, so I wonder if they are detritus from the old computer that this one replaced. I used DaisyDisk to delete it all, and I now have 800 GB of free space instead of 200. I am also going through Carbon Copy Cloner to delete (and turn off) snapshots. Thank you, everybody, for all the advice.
 


Ric Ford

MacInTouch
I thought this update on ZFS was interesting...
Michael Larabel/Phoronix said:
OpenZFS 2.0 Out In 2020 With Unified Linux/FreeBSD Support, OpenZFS 3.0 With macOS
Taking place this past week in San Francisco was the annual OpenZFS Developer Summit. As usual, Matthew Ahrens as the co-founder of Sun ZFS and current OpenZFS contributor at Delphix talked about the state of the open-source ZFS efforts in his keynote.
...
OpenZFS 2.0 will be out next year as the series succeeding ZFS On Linux 0.8. OpenZFS 2.0 will focus on the unified Linux/FreeBSD support, redacted send/receive, Zpool wait, performance improvements, and other changes. Some of the performance work will include fast clone deletion, log spacemap, and metaslab performance work. Also possible OpenZFS features are DRAID and Direct I/O handling but still a work-in-progress.

The OpenZFS community will be working on annual major releases so OpenZFS 3.0 is already being talked about for 2021. OpenZFS 3.0 will hopefully see official macOS support.
 


.... The easiest way to tell what your Recovery Partition is, is to boot to the startup manager (hold down the Option, a.ka. Alt, key at boot). This should show you the Recovery Partition and its (macOS / OS X) version.
That has worked in the past, but I think APFS changes things a bit. APFS puts the recovery volume into the same APFS Container as the macOS system volume. It isn't a separate disk partition, as with the HFS systems, it is just a different unmounted part of the same Container (which resides inside a disk partition).

I think the standard Apple approach now is to keep the recovery partition hidden unless you explicitly invoke recovery. My internal drive, on which I installed a modern macOS with APFS, doesn't present that recovery volume when the option key is down. Haven't tested on a newer system (and firmware) with perhaps more APFS support.

If booted into the Recovery mode, you can then start Terminal and retrieve the software version using either of two commands below.
Bash:
sw_vers
or
Bash:
system_profiler  SPSoftwareDataType
The second one has a bit more information, but both contain the macOS version number.
 


That has worked in the past, but I think APFS changes things a bit. APFS puts the recovery volume into the same APFS Container as the macOS system volume. It isn't a separate disk partition, as with the HFS systems, it is just a different unmounted part of the same Container (which resides inside a disk partition).

I think the standard Apple approach now is to keep the recovery partition hidden unless you explicitly invoke recovery. My internal drive, on which I installed a modern macOS with APFS, doesn't present that recovery volume when the option key is down. Haven't tested on a newer system (and firmware) with perhaps more APFS support.

If booted into the Recovery mode, you can then start Terminal and retrieve the software version using either of two commands below.
Bash:
sw_vers
or
Bash:
system_profiler  SPSoftwareDataType
The second one has a bit more information, but both contain the macOS version number.
This should work, too:
Bash:
cat /System/Library/CoreServices/SystemVersion.plist
 


That has worked in the past, but I think APFS changes things a bit. APFS puts the recovery volume into the same APFS Container as the macOS system volume. It isn't a separate disk partition, as with the HFS systems, it is just a different unmounted part of the same Container (which resides inside a disk partition).
I think the standard Apple approach now is to keep the recovery partition hidden unless you explicitly invoke recovery. My internal drive, on which I installed a modern macOS with APFS, doesn't present that recovery volume when the option key is down. Haven't tested on a newer system (and firmware) with perhaps more APFS support.
If booted into the Recovery mode, you can then start Terminal and retrieve the software version using either of two commands below.
Bash:
sw_vers
or
Bash:
system_profiler  SPSoftwareDataType
The second one has a bit more information, but both contain the macOS version number.
This post finally got me to do something about a many months-old problem with Recovery Mode on my 2018 Mac Mini. I'm running macOS 10.14.6 with all the updates, but I've been unable to start into Recovery Mode (both from restart and startup). I'd just get the spinning world globe which would finally end in an error. This also happened when I was using a macOS 10.14.6 external drive which was able to go into recovery on my 2012 MacBook Pro.

I decided to take a drastic step. I completely erased my internal SSD and did a clean install of macOS 10.15.1. After this, I could get into recovery mode easily, including from my external macOS 10.14.6 SSD, as well. At this point the recovery volume size was 543.8 MB.

Next, I added an additional APFS volume to the same container as the macOS 10.15.1 volume(s) and used Carbon Copy Cloner to copy a clone of my macOS 10.14.6 volume to the new volume. I could now get to recovery mode from both macOS 10.14.6 and 10.15.1. The recovery partition size had grown to 1 GB.

I then erased the macOS 10.15.1 volume(s) from my internal SSD. Now I could still login to macOS 10.14.6 and get into recovery mode. The recovery volume size had dropped to 510.4 MB, the same as on my macOS 10.14.6 clone.

Apparently Apple picks whichever recovery mode goes with the previously chosen startup drive (including external drives). I don't know if you can change that choice, and I still don't know why I couldn't get into recovery mode before the steps listed above. Probably some T2 black magic.
 


Ric Ford

MacInTouch
APFS/T2 compatibility problems with Samsung T5 devices:
Bombich Software said:
Help! My clone won't boot! | Carbon Copy Cloner | Bombich Software
... Some users have reported that the Samsung T5 Portable SSD cannot function at all as a bootable device on the T2-based MacBook Pro 2018. Efforts even to install macOS Mojave onto this device fail to produce a bootable volume. This is a popular enclosure that we've seen great success with, and so far these reports are limited to the 2018 MacBook Pro.

Catalina: We have received numerous reports of general bootability problems with this device on macOS Catalina.

The Samsung T5 Portable SSD (and also the Transcend StoreJet SSD) also introduces an exceptional delay during startup (on any Mac, not just T2 Macs), whether you're attempting to boot from that device or your Mac's internal hard drive. This appears to be a compatibility problem between the Mac's firmware and this particular SSD when the SSD is formatted as APFS and when the SSD has an installation of macOS (whether placed there via cloning or via the Installer). To avoid this delay, and only if your Mac is running macOS Mojave or an earlier OS, we recommend formatting these SSDs as HFS+ until the compatibility problem is resolved:
  1. Open Disk Utility
  2. Choose Show all devices from the View menu
  3. Select the top-level "parent" device of the Samsung T5 SSD in Disk Utility's sidebar
  4. Click the Erase button in the toolbar
  5. Set the format to Mac OS Extended, Journaled, set the Scheme to GUID Partition Map. and give the new volume a name
  6. Click the Erase button
  7. Open CCC and re-select the new volume as the destination, then run the backup task
Note: If you have a T2 Mac, please bear in mind that T2 Macs cannot boot from an encrypted HFS+ formatted device. The Samsung T-series devices will not be a suitable backup device for your T2-based Mac if you require that the backup disk is encrypted.
 


Ric Ford

MacInTouch
I don't know much, but I suspect that Catalina may have had a problem booting from an external drive with a partition.
I wonder if this could be the issue:
Bombich Software said:
Help! My clone won't boot!

System Integrity Protection prohibits modifications to the current startup disk's Preboot helper partition


If you add an APFS volume to your current startup disk's APFS container, the macOS bless facility will be unable to update the container's Preboot volume to include support files for the second partition. Multiple, bootable volumes within a single APFS container is a supported configuration, but you can only make the second volume bootable if you boot from some other startup disk for the duration of the cloning procedure. Likewise, you will be unable to change the startup disk selection to the second volume while booted from the first volume. The solution is the same as above — use the Startup Manager (boot your Mac while holding down the Option key) to temporarily change the startup disk selection, then set the startup disk explicitly to the new startup volume.

Alternatively, you can create a separate partition on your startup disk (rather than adding a second volume to the same parent APFS container) and make your backup to that separate partition.
  1. Open Disk Utility
  2. Choose "Show all devices" from the View menu
  3. Click on the top-most parent device for your Macintosh HD volume
  4. Click the "Partition" button in the toolbar
  5. When Disk Utility tries to discourage you from doing this, click the "Partition" button
  6. Click the "+" button to add a second APFS-formatted partition on the startup disk

#APFS #boot #partitions #SIP
 


APFS/T2 compatibility problems with Samsung T5 devices...
I read this on Bombich Software's website yesterday, unfortunately after I'd backed up my 2014 iMac to a Samsung T5 formatted as APFS. The boot process consistently hangs about 3/4 of the way through. I waited up to 10 minutes on one attempt in the hope it would eventually complete, but no luck.

I suppose I could reformat the SSD as HFS+, but it's my understanding it won't be bootable if and when I update from Mojave to Catalina. Interestingly, the warning says "until the compatibility problem is resolved," which begs the question who is actively attempting to find a resolution? Samsung? Apple?

Has anyone had any success creating a bootable APFS-formatted Samsung T5 under Mojave or Catalina? I'd prefer not to have to return the device. Thanks in advance.
 


Has anyone had any success creating a bootable APFS-formatted Samsung T5 under Mojave or Catalina? I'd prefer not to have to return the device. Thanks in advance.
I'm running one right now. I use it to create a backup clone of my iMac running Catalina, and last week I took it with me on my Thanksgiving trip to visit my brother and ran off of it all week on his iMac. No issues.
 


I'm running one right now. I use it to create a backup clone of my iMac running Catalina, and last week I took it with me on my Thanksgiving trip to visit my brother and ran off of it all week on his iMac. No issues.
That's good to hear, Michael. Is the device encrypted with FileVault or any other method?

Interestingly, I wrote to Bombich Software earlier and got an almost immediate reply. Paraphrasing, they said the T5 started having issues with each OS update making it less functional and advised against using it as an APFS volume.

I wonder what secret sauce I have to add to make it work, or is every APFS-formatted T5 going to fail to boot sooner or later, even if the drive is working currently?
 



I read this on Bombich Software's website yesterday, unfortunately after I'd backed up my 2014 iMac to a Samsung T5 formatted as APFS. The boot process consistently hangs about 3/4 of the way through. I waited up to 10 minutes on one attempt in the hope it would eventually complete, but no luck.
I suppose I could reformat the SSD as HFS+, but it's my understanding it won't be bootable if and when I update from Mojave to Catalina. Interestingly, the warning says "until the compatibility problem is resolved," which begs the question who is actively attempting to find a resolution? Samsung? Apple?
Has anyone had any success creating a bootable APFS-formatted Samsung T5 under Mojave or Catalina? I'd prefer not to have to return the device. Thanks in advance.
I actually have two T5's, one 512GB and one 1TB. Both are clones from macOS Mojave and Catalina, respectively, and both boot from my mid-2019 MacBook Pro just fine. (All storage is formatted as APFS and unencrypted.)
 



I am running at least five T5s and one T3. The 2TB ones are all partitioned in two. One of them is a 1TB with no partitions. They all boot, and four of them are encrypted via FileVault. They are all APFS and I had to re-format them when I went to Catalina, because Carbon Copy Cloner told me to, and I listen to Carbon Copy Cloner and Mike Bombich!

To encrypt via Filevault, I had to boot from them in order to turn Filevault on. I had initial problems doing this with one Sandisk Extreme drive but got that to boot eventually, as well. Still not absolutely sure where that problem came from, although I initially thought it was the MacBook Pro I was using. I'm not so sure now. Anyway, no problems here with Samsung T5s for me. Hopefully, that won't change.
 


One other thing - I have gotten other drives to boot from all kinds of enclosures, from cheap Orico ones holding 2.5" SSDs to OWC Thunderbays with spinners - they are too slow to actually work with, but I have booted from them and turned on Filevault. The only enclosure that has consistently failed so far as been the Thunderbay 6-Bay enclosure from OWC. Neither the drives nor the internally mounted NVMe blade has gotten past that deadly 3/4" status bar thing, although they all show up in Startup Manager.
 


I've set up many, many client iMacs (with hard drives or Fusion drives) to boot Mojave off of a Samsung T5 formatted as APFS without issue -- usually, but not always, unencrypted. (I have less experience with T1/T2 models.)
 


I read this on Bombich Software's website yesterday, unfortunately after I'd backed up my 2014 iMac to a Samsung T5 formatted as APFS. The boot process consistently hangs about 3/4 of the way through. I waited up to 10 minutes on one attempt in the hope it would eventually complete, but no luck.

I suppose I could reformat the SSD as HFS+, but it's my understanding it won't be bootable if and when I update from Mojave to Catalina. Interestingly, the warning says "until the compatibility problem is resolved," which begs the question who is actively attempting to find a resolution? Samsung? Apple?

Has anyone had any success creating a bootable APFS-formatted Samsung T5 under Mojave or Catalina? I'd prefer not to have to return the device. Thanks in advance.
I have a small business with a dozen iMacs, circa 2014-2017, all booting off external T5's, some formatted as APFS with Disk Utility, some auto-formatted to APFS via Mojave installer, all running Mojave. All work fine.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts