MacInTouch Amazon link...

APFS / file systems

Channels
Apple, Security, Other, Products
What's very conspicuously absent: Linux filesystems, which seems strange, as macOS is also Unix-based, and Linux is open source.
For those occasions when I've needed to work with Linux ext filesystems on my Mac, I've had good luck with Paragon Software's extFS for Mac product. It retails for ~$40, but I've seen it included with bundles for significantly less every now and then.

Another option, of course, would be to keep a Linux system handy, especially if there is a need to access less frequently used filesystems, like ZFS, ReiserFS, or XFS. I'd expect a Linux virtual machine on a Mac would work, too, as long as the vm controls the USB device or other device containing the filesystem of interest, but I haven't tried it. One caveat is that not all Linux distributions enable support for all Linux filesystem types by default, so additional configuration may be required in some cases.
 


Ric Ford

MacInTouch
For those occasions when I've needed to work with Linux ext filesystems on my Mac, I've had good luck with Paragon Software's extFS for Mac product...
I've had poor experiences with Paragon's other software (e.g. Hard Disk Manager), so I'd been avoiding their product, but it's good to know that it's been working for you.

There's also FUSE for macOS along with fuse-ext2 and fuse-ext4 but there are a lot of issues with that path, including dire warnings about writing to an ext volume and really challenging issues involved with installation and operation of the extension.
 


Ric Ford

MacInTouch
More importantly, if Apple were to incorporate a GPL-licensed piece of code like the implementation of the EXT4 file system into OS X, the license would require that much or all of OS X be released in source form to the public, effectively killing a business model which relies on keeping the implementation of innovation protected.
For those occasions when I've needed to work with Linux ext filesystems on my Mac, I've had good luck with Paragon Software's extFS for Mac product.
I'm confused about how Paragon can do a commercial ext filesystem product but Apple can't provide that functionality in macOS.
 


Oracle's Solaris uses the Sun-developed, Oracle-owned ZFS. It's apparently possible to use it in other Linux "distros", but the litigious Oracle in the background has held it back.

Btrfs is a b-tree file system some developers hope will replace the older ext series that's the Linux default. Designed to offer snapshots, it is an option on Synology.

The only file system I've really paid attention to is HFS+, but on Linux, I've followed the recommendation of an old hand to stick with ext4, mostly because it is internally compatible with Linux systems, and while not perfect, works reliably.

I'm curious if APFS will ultimately, much as the T2, add bricks to the wall around Apple's garden?
 


I've had poor experiences with Paragon's other software (e.g. Hard Disk Manager), so I'd been avoiding their product, but it's good to know that it's been working for you. There's also FUSE for macOS along with fuse-ext2 and fuse-ext4 but there are a lot of issues with that path, including dire warnings about writing to an ext volume and really challenging issues involved with installation and operation of the extension.
Our Synologies are formatted ext4. They're [as file servers] a very effective way to avoid the conversion problem. My real issue as a user of Mac and Linux is that I can format ext4 encrypted portable drives on Linux and not worry about losing one, and on Macs I've used encrypted DMGs on either exFAT or HFS+ portables and have some HFS+ external SSDs that are fully encrypted, [but the different Linux and Mac] encryption keeps them from interchanging files.
 


I'm confused about how Paragon can do a commercial ext filesystem product but Apple can't provide that functionality in macOS.
It's not a matter of "can't", but "won't".

There is the issue of GPL licensing if they use Linux code. FreeBSD includes a BSD-licensed port of ext2, but not versions 3 or 4.

And then there's the matter that anything they bundle, they need to support. Unless they believe including support for ext (or other Linux-specific file systems) will boost Mac sales, that's an added expense with questionable payback, especially when those users who require support can add it themselves via third-party products.
 


Ric Ford

MacInTouch
... Unless they believe including support for ext (or other Linux-specific file systems) will boost Mac sales, that's an added expense with questionable payback, especially when those users who require support can add it themselves via third-party products.
That's OK, I guess, if Paragon's software is really good and solid - otherwise, not so much; other options are truly painful. (As far as support goes, I guess it won't make business sense for Apple until they can use it to sell more subscriptions/services to even more people, as with Apple's Windows software and Mac OS X 10.6 App Store update.)
 


Maybe someone else could check their Mojave installation and confirm what I'm seeing. I have a lot of third-party software installed on this system, but it seems like this 9P software is coming from Apple.
I got the same list as you have - my MacBook Pro is running Mojave.
One constant annoyance to me is why Apple won't implement full read/write support for NTFS. Third-party solutions are invariably slow and/or flaky.
 


Maybe someone else could check their Mojave installation and confirm what I'm seeing. I have a lot of third-party software installed on this system, but it seems like this 9P software is coming from Apple.
Any excuse to pretend I can hack:
  1. Mount InstallESD.dmg that is in the Mojave 10.14.3 installer package.
  2. Open InstallESD/Packages/Core.pkg using Pacifist.
  3. Look in Contents of Core.pkg/sbin
  4. Yes, mount_9p is there.
 


Maybe someone else could check their Mojave installation and confirm what I'm seeing. I have a lot of third-party software installed on this system, but it seems like this 9P software is coming from Apple.
On my iMac 17,1 running Mojave 10.14.3
Bash:
cd /sbin; ls -1 mount_*
mount_9p
mount_acfs
mount_afp
mount_apfs
mount_cd9660
mount_cddafs
mount_devfs
mount_exfat
mount_fdesc
mount_ftp
mount_hfs
mount_msdos
mount_nfs
mount_ntfs
mount_smbfs
mount_udf
mount_webdav
 


Maybe someone else could check their Mojave installation and confirm what I'm seeing. I have a lot of third-party software installed on this system, but it seems like this 9P software is coming from Apple.
Yup. Confirming on macOS 10.14.3 [the same result].
 


The weird ones here are ACFS [...]
This is a different ACFS; it’s the Apple Clustered File System, better known by its marketing name, Xsan. It's a shared file system, meaning that a disk (or set of disks) with ACFS can be directly connected to multiple computers at the same time, and they can all read from & write to the file system simultaneously — instead of a NAS (network-attached storage), it’s a SAN (storage area network).

Xsan is licensed from Quantum, who market a newer version (including some more advanced features, like automatically moving files between disk and tape) under the name StorNext.
 


9P strikes me as weird, especially if it was just added. I'm wondering if some people at Apple are looking to integrate some Plan 9 software concepts (if not applications) into future releases of macOS.
Running strings against /sbin/mount_9p reveals that it’s tied into AppleVirtIO. Looking at /System/Library/Extensions/AppleVirtIO.kext, it’s marked to match against QEMU (an open-source machine emulator, somewhat similar to VirtualBox or VMware). QEMU uses a virtual Plan 9 file system for its shared folders.

Why is this supported? Good question. Perhaps Apple’s using QEMU internally to emulate and test hardware before it’s physically ready to run software, or perhaps they have other emulation plans for the future. Some people have noticed support for other QEMU devices in Mojave as well.
 


I'm confused about how Paragon can do a commercial ext filesystem product but Apple can't provide that functionality in macOS.
I'm confused by a lot of things Apple chooses to support... or not to support.

Somewhere on that list would be easy write access to Microsoft NTFS filesystems, which presumably has a much larger potential user base on the Mac than reading/writing the various Linux filesystems would have.
 


Ric Ford

MacInTouch
Why is this supported? Good question. Perhaps Apple’s using QEMU internally to emulate and test hardware before it’s physically ready to run software, or perhaps they have other emulation plans for the future. Some people have noticed support for other QEMU devices in Mojave as well.
Any chance this is for Apple's "Marzipan" iOS emulation system - the one that runs Apple iOS apps, such as News, Stocks, News, and Voice Memo, on Mojave?
 



Oracle's Solaris uses the Sun-developed, Oracle-owned ZFS. It's apparently possible to use it in other Linux "distros", but the litigious Oracle in the background has held it back.
ZFS on MacOS works great.
OpenZFS said:
Welcome to OpenZFS
OpenZFS was announced in September 2013 as the truly open source successor to the ZFS project. Our community brings together developers from the illumos, FreeBSD, Linux, OS X and Windows platforms, and a wide range of companies that build products on top of OpenZFS.

OpenZFS is an outstanding storage platform that encompasses the functionality of traditional filesystems, volume managers, and more, with consistent reliability, functionality and performance across all distributions...
That includes FreeBSD, Linux, macOS and Windows.
 


I got the same list as you have - my MacBook Pro is running Mojave.
One constant annoyance to me is why Apple won't implement full read/write support for NTFS. Third-party solutions are invariably slow and/or flaky.
I purchased Paragon’s NTFS client as part of a bundle. I’ve found it easy to use and reliable. However, my experience is limited to mounting NTFS USB drives I receive from video/film transfer companies. Interestingly, Apple’s read-only NTFS support will not recognize those drives (at least with High Sierra). Paragon’s software has no trouble with those or any other NTFS disks I’ve thrown at it.
 


Running strings against /sbin/mount_9p reveals that it’s tied into AppleVirtIO. Looking at /System/Library/Extensions/AppleVirtIO.kext, it’s marked to match against QEMU (an open-source machine emulator, somewhat similar to VirtualBox or VMware). QEMU uses a virtual Plan 9 file system for its shared folders.

Why is this supported? Good question. Perhaps Apple’s using QEMU internally to emulate and test hardware before it’s physically ready to run software, or perhaps they have other emulation plans for the future. Some people have noticed support for other QEMU devices in Mojave as well.
Just saw mention of 9P with regard to Windows 10, being used for the Linux file access:
The Inquirer said:
Windows 10 will soon allow direct access to Linux files
You'll also be able to access your Linux files in Powershell (but not CMD), thanks to a newly added 9P protocol file server which treats Windows as a client.
So maybe Apple is doing something similar to make it better at Linux file access in some manner.
 


I purchased Paragon’s NTFS client as part of a bundle. I’ve found it easy to use and reliable. However, my experience is limited to mounting NTFS USB drives I receive from video/film transfer companies. Interestingly, Apple’s read-only NTFS support will not recognize those drives (at least with High Sierra). Paragon’s software has no trouble with those or any other NTFS disks I’ve thrown at it.
I’ve used the ext support from Paragon to successfully pull data off a failed Buffalo NAS drive (the hardware had failed, but the drives were fine). Worked well for those purposes. I’ve done some extended copies, and checksums always came out clean.
 


Any chance this is for Apple's "Marzipan" iOS emulation system - the one that runs Apple iOS apps, such as News, Stocks, News, and Voice Memo, on Mojave?
I don't think so. First, what Apple introduced doesn't seem to be a emulation system. In the "State of the Platform" presentation at WWDC the presenter mentioned recompiling for iOS and macOS. The screen resources are different (due to screen sizes). The presentation also mentioned "cleaning up" Core Foundation classes that had drifted apart (probably small annoying forks, like how iOS HFS+ had drifted away from Mac HFS+).

Second, Plan 9 is a distributed operating system. The file-sharing protocol for different/distributed OS installs is the 9S file protocol. The quirky thing in an iOS/macOS context is that they actually have the same file system: APFS. It would have very strange to make an application that wanted to 'talk' to APFS have to go through 9S protocol if the app is actually sitting directly on top of macOS (not distributed) with an APFS file system. (For Windows, it partially makes sense, because NTFS is not a native Linux file system. It actually is a different file system implementation. iOS and macOS they are the same... so why?)

In my opinion, 9S makes more sense perhaps as a file bridge between macOS (on x86) and T2/bridgeOS (on ARM), where Apple actually does have distributed OS instances. Plan9/Inferno is a design to deploy some "embedded sized" devices, which the T2 would match up with (i.e., relatively low RAM), One of Plan9's apps was 'plumber', which served as a foundation to do inter-process communication. It is done over 9S protocol, so that "interprocess" can span OS instances.

9S has authentication, so it isn't just 'raw' TCP/IP pipes between the macOS instance and the bridgeOS instance, if Apple sets up the security right.
 


Just saw mention of 9P with regard to Windows 10, being used for the Linux file access:
So maybe Apple is doing something similar to make it better at Linux file access in some manner.
This Windows solution leverages a 9P server running in a virtual Linux instance. Also, macOS already has NFS (if you have an "up and running" Linux instance going). I'm sure 9S is 'thinner' than NFS. However, the baseline of having a whole Linux instance running to get to the file system subset is already past 'thin'.

It probably does work decently with Linux instances running in Fusion/Parallels/VirtualBox. (i.e., fire up u9fs in your Linux instance and mount the 'remote' file system on the Mac side).

I think Apple played a bit with getting something like FreeBSD's bhyve to work, but I doubt they are about to go down a very similar path as Windows Subsystem for Linux. First, the 3rd-party virtualization solutions are there. Second, the Unix utilities at the macOS command line are just as "POSIX"-flavored as the Linux ones. (The whole point was the Windows command line never was highly "Unix like". macOS has a POSIX certification, technically, more than Linux has.)
 


This Windows solution leverages a 9P server running in a virtual Linux instance. ... the baseline of having a whole Linux instance running to get to the file system subset is already past 'thin'.
It's worth noting that Windows 10 Pro installations (via the HyperV virtualization engine) have built-in support (optional install) for a Ubuntu Linux shell. Given that, a file-access wedge that leverages the Linux subsystem is not surprising.

It's worth noting that the article goes on to say:
It's not perfect, and at the moment, it will only work while the distro is running, though there are plans to remove this requirement later in development. All Linux files are treated as a network resource.
So I think we can safely assume that this mechanism is a stopgap until Microsoft can develop a native file system driver.

And I agree that there is no need for Apple to do this because they've already got a UNIX core in macOS, so there's no need to create a parallel runtime environment in order to quickly port a feature from Linux.
 


Adding on to some of the earlier comments about using the Windows Subsystem for Linux, it's not just Ubuntu that is supported on Windows 10 Pro. Ubuntu was the first to be released, but Microsoft also currently features Debian, openSUSE, SUSE Linux Enterprise Server, and Kali Linux in its app store, and other distributions are available. If you're really ambitious, you even can create your own distribution, but if that's you, you probably already know that.

For everyone else, keep in mind that WSL is not a full GUI desktop environment, and it has real limitations in function because it uses the NT kernel, not the Linux kernel. In other words, native Linux kernel extensions and customizations won't work, and there can be issues with sound, graphics, and other hardware-specific features. It's really intended primarily for developer use. That said, it is a good way to get a true Linux userland environment on a Windows system, and you can run many graphical apps if you install X11 software on the Windows side. You can even install multiple Linux distributions at once. However, if you'd really like the full Linux experience on a Windows machine, you'd be better off using a virtual machine or setting up a multi-boot system.
 


On my iMac 17,1 running Mojave 10.14.3
Bash:
cd /sbin; ls -1 mount_*
mount_9p
mount_acfs
mount_afp
mount_apfs
mount_cd9660
mount_cddafs
mount_devfs
mount_exfat
mount_fdesc
mount_ftp
mount_hfs
mount_msdos
mount_nfs
mount_ntfs
mount_smbfs
mount_udf
mount_webdav
I have those, as well, in macOS 10.14.3, but all except mount_9p, mount_afp, mount_devfs, mount_fdesc, mount_nfs, mount_smbfs, and mount_webdav are links to files in /System/Library/Filesystems, e.g.:
Code:
mount_ftp -> /System/Library/Filesystems/ftp.fs/Contents/Resources/mount_ftp
 


While I am still trying to figure out Apple's new Disk Utility quirks, I selected an APFS disk I had formatted via command line. Now Disk Utility gives me all the APFS options, but none of the HFS+ options.
I kept a disk untouched for the last month or two, so I maintained a pristine test setup. Now when I want to format this disk, Disk Utility offers me all the options it should - from a non-admin account and booted from external disk. I guess Apple fixed it in the macOS 10.14.3 update.
 


I had similar result on a 2017 iMac, except that the "44 minutes remaining stage" lasted an incredibly long time. I swear it was at least a nerve-wracking 20 minutes, while the time stayed at 48 minutes remaining, then changed to 47 minutes, only to go back to 48 minutes. And then eventually repeat. And again. [...] Eventually it did complete. What I'm wondering is what in the world was it doing? It couldn't take that long just to update some files.
I figured out why the High Sierra security updates have been taking so long on my iMac.

The security update is not just a security update. It is also an unannounced beta test of Mojave. The long phase of the update is actually a dry run of the APFS conversion, which takes a long time on my multi-terabyte Fusion drive.

Now that I know what to look for, I can see that it did the dry run on June 19, 2018, July 28th, November 17th, December 15th, March 9th 2019, and yesterday.

The evidence is in /var/log/install.log. Look for the /sbin/apfs_hfs_convert --dry-run command, followed by APFS Dry Run: Received Progress messages.

What's interesting is that there have been no reports of this on the web. I mean, we knew after iOS 10.3 that Apple was doing dry runs in iOS 10.1 and 10.2, but not that it was doing it on macOS in security updates.
 


I figured out why the High Sierra security updates have been taking so long on my iMac.

The security update is not just a security update. It is also an unannounced beta test of Mojave. The long phase of the update is actually a dry run of the APFS conversion, which takes a long time on my multi-terabyte Fusion drive.

Now that I know what to look for, I can see that it did the dry run on June 19, 2018, July 28th, November 17th, December 15th, March 9th 2019, and yesterday.

The evidence is in /var/log/install.log. Look for the /sbin/apfs_hfs_convert --dry-run command, followed by APFS Dry Run: Received Progress messages.

What's interesting is that there have been no reports of this on the web. I mean, we knew after iOS 10.3 that Apple was doing dry runs in iOS 10.1 and 10.2, but not that it was doing it on macOS in security updates.
Couldn't find it in the log for the Sierra update.
 



Ric Ford

MacInTouch
Howard Oakley tries to explain how Apple manages and presents free space in APFS...
Eclectic Light Co. said:
Quantum computing and APFS: free and used space
...
APFS poses five significant problems in measuring free space.
...
So which is right: Finder or the disk utilities? The quantum computing answer is both, depending on what you want to know, although I personally don’t like answers as given by the Finder...
 


Howard Oakley at Eclectic Light Co said:
So which is right: Finder or the disk utilities? The quantum computing answer is both, depending on what you want to know, although I personally don’t like answers as given by the Finder...
Finder Get Info reports size as two numbers: exact bytes and then a value "on disk". For example, from Howard's article:

Size: 116,912,884,045 bytes (116.91 GB on disk)

The "on disk" value is the sum of the disk blocks used for the files. This can be different from reported file size for various reasons, such as overhead due to block sizes and reduction on disk due to HFS file compression.

In my opinion:
  • The reported Size should be the same as it is today: the file size independent of how it is stored, or the sum of those sizes for a folder. This size should stay the same if you duplicate the files or copy them to a different device.
  • The "on disk" size should be the sum of the disk blocks occupied by whatever file or folder is being inspected.
Let's say we have a file that occupies 1 GB on disk on an APFS volume. If I duplicate that file, then Get Info on the file or its duplicate should show the same size: 1 GB on disk. But if I do a Get Info on a folder or drive that contains both files, then the On Disk space should only show 1 GB.

So, Get Info on the entire drive should show "on disk" the total amount of space that the volume is currently using. The reported size could be much larger.
 


Finder Get Info reports size as two numbers: exact bytes and then a value "on disk". For example, from Howard's article:
Size: 116,912,884,045 bytes (116.91 GB on disk)
The "on disk" value is the sum of the disk blocks used for the files. This can be different from reported file size for various reasons, such as overhead due to block sizes and reduction on disk due to HFS file compression. In my opinion:
  • The reported Size should be the same as it is today: the file size independent of how it is stored, or the sum of those sizes for a folder. This size should stay the same if you duplicate the files or copy them to a different device.
  • The "on disk" size should be the sum of the disk blocks occupied by whatever file or folder is being inspected.
Let's say we have a file that occupies 1 GB on disk on an APFS volume. If I duplicate that file, then Get Info on the file or its duplicate should show the same size: 1 GB on disk. But if I do a Get Info on a folder or drive that contains both files, then the On Disk space should only show 1 GB. So, Get Info on the entire drive should show "on disk" the total amount of space that the volume is currently using. The reported size could be much larger.
I don't think you're commenting on the same thing.

You seem to be talking about the cumulative effect of all those little bits of files that are reported as using space but are only using 1-99% of that space, so when there are 20 files of the same size, they 'save' the equivalent space of one file, which is the same on HFS/NTFS/FAT.

The APFS issue is that the Finder will say you have 100 GB free, but investigate the same drive in Disk Utility, and you may see 50 GB free - due to the way APFS copies/reports the usage. For example, I tried to use the 100 GB free space (reported in the Finder window status bar) on my internal SSD to temporarily store a 60GB file (a Windows 10 VM), but the OS said I couldn't copy the file, as I only had 50 GB free.

It seems that APFS is reporting the space as free but reserving that space in case your copies are changed and require that space.

It's also compounded by the fact that APFS keeps lots of 'snapshot' files, which can eat up large amounts of disk space on an SSD.
 


... It seems that APFS is reporting the space as free but reserving that space in case your copies are changed and require that space. It's also compounded by the fact that APFS keeps lots of 'snapshot' files, which can eat up large amounts of disk space on an SSD.
So, APFS isn't accurately reporting disk usage, but if you haven't cleared out your old iPhoto Library, the Finder won't, either (due to the hard links). Seems like Apple wants it both ways... or is it neither?

I'm afraid APFS is another example of a butterfly keyboard - once the first step was taken, common sense be damned. (And does anyone really have any problems with HFS+ disks in any macOS since 10.6.8? Maybe I'm the lucky one.)
 


I just read here that external hard drives upgraded to Mojave are not automatically converted to APFS. Is this true? I have an external hard drive with Sierra that I've wanted to upgrade, purely because my iMac, which shipped with Mojave, can't boot Sierra (well, I haven't actually tried booting it on the new iMac)...but I haven't done the upgrade because I really didn't want the file system to change.
 


I just read here that external hard drives upgraded to Mojave are not automatically converted to APFS. Is this true? I have an external hard drive with Sierra that I've wanted to upgrade, purely because my iMac, which shipped with Mojave, can't boot Sierra (well, I haven't actually tried booting it on the new iMac)...but I haven't done the upgrade because I really didn't want the file system to change.
I believe that:
  • The Mojave installer will convert any drive that it is being installed on.
  • Upgrading to Mojave does not convert other attached external drives to APFS.
  • Mojave does not support booting from HFS [See below. -MacInTouch]
It is possible to get Mojave on to an HFS volume, such as by cloning from an APFS Mojave boot drive. And once it is on HFS, rumors are that it will boot. But that's not a supported configuration; it really expects that it will boot from APFS.

So this means that if you want to install Mojave on your external drive, it will be converted to APFS, and probably you should keep it that way.

(This also means that you can't use a single volume as both a Mojave boot volume and a Time Machine drive, which is something that was possible in previous releases.)
 


So this means that if you want to install Mojave on your external drive, it will be converted to APFS, and probably you should keep it that way.
That's depressing. Looks like I will have to buy yet another external hard drive before the conversion. I just can't take the chance.

In the case of drives with multiple partitions, do you know whether the other partitions are left alone, since I'm only installing on one partition? Or is it an all-or-nothing proposition?
 


I believe that:
  • The Mojave installer will convert any drive that it is being installed on.
  • Upgrading to Mojave does not convert other attached external drives to APFS.
  • Mojave does not support booting from HFS
It is possible to get Mojave on to an HFS volume, such as by cloning from an APFS Mojave boot drive. And once it is on HFS, rumors are that it will boot. But that's not a supported configuration; it really expects that it will boot from APFS.

So this means that if you want to install Mojave on your external drive, it will be converted to APFS, and probably you should keep it that way.

(This also means that you can't use a single volume as both a Mojave boot volume and a Time Machine drive, which is something that was possible in previous releases.)
I can verify that Mojave is bootable under HFS+, but then you cannot update the OS, because to do updates requires that volumes be formatted as APFS.
 


That's depressing. Looks like I will have to buy yet another external hard drive before the conversion. I just can't take the chance.

In the case of drives with multiple partitions, do you know whether the other partitions are left alone, since I'm only installing on one partition? Or is it an all-or-nothing proposition?
I can only speculate, since I'm not on Mojave.

The apfs_hfs_convert command can convert either a single HFS volume (i.e. partition) or an entire disk.

The question is, what does the Mojave installer do? On the one hand, it needs to convert the Recovery HD partition into a Recovery APFS volume. On the other hand, it would be really bad for it to convert non-HFS partitions, such as used for Boot Camp.

Google doesn't have an answer. But I bet there's one way to avoid the problem: convert the partition to APFS manually, before installing Mojave. If it is already APFS, Mojave shouldn't need to convert it.

I'm going to run into this when I upgrade to Mojave. My external backup drive has two partitions: one is a clone and the other for Time Machine. So that will need to have one APFS partition and one HFS.
 


I can verify that Mojave is bootable under HFS+, but then you cannot update the OS, because to do updates requires that volumes be formatted as APFS.
Clearly that means any effort made to retain HFS formatting is a waste of time. The gymnastics one would have to go through with each update wouldn't be worth it.
 


In the case of drives with multiple partitions, do you know whether the other partitions are left alone, since I'm only installing on one partition? Or is it an all-or-nothing proposition?
I'm going to run into this when I upgrade to Mojave. My external backup drive has two partitions: one is a clone and the other for Time Machine. So that will need to have one APFS partition and one HFS.
I'm in a similar boat as Michael; I want to move to Mojave before 10.15 comes out, and my iMac is running Sierra from an internal (not external) Apple SSD.

This SSD is currently partitioned into 4 separate partitions (not counting the Recovery drive), all HFS+. Other than the Sierra partition and the Recovery partition, the rest of the partitions are not bootable.

If anyone has experience with a similar partitioned SSD configuration when they updated their Mac to Mojave. I'd be very interested.

(Thanks to everyone contributing info to this thread. I'd already planned to Carbon Copy Clone my internal partitions to an external drive before moving to Mojave; but now I will make sure that I disconnect the external backup drive before installing Mojave.)
 


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

Latest posts