Fusion Drive on ARM Based Macs

[Brian33]

You don't need to boot into Recovery Mode to create a Fusion drive from external drives.

I think the OP was about making a bootable Fusion drive with the internal drive + an external drive... does that work, or not?

 

[DaveFromCampbelltown]

I think the OP was about making a bootable Fusion drive with the internal drive + an external drive... does that work, or not?

I agree. However I just wanted to add that you did not need to if you wanted to create a Fusion drive from external drives. I just felt it wasn't clear.

 

[gilby101]

I don't see why ALL of the volumes have to be on the Fusion container for this to be useful. Why does Preboot, for example, need to be in the Fusion container for this the idea to be useful, as long as the Data partition is.

A standard install has multiple volumes inside the APFS container. So I was asking if that is what happens with a Fusion drive. I agree that, from the user perspective, all that is wanted is for the Data volume to be in the container in the Fusion drive. But can macOS install and boot in that situation?

You don't need to boot into Recovery Mode to create a Fusion drive from external drives.

I am sure that is true for a data only Fusion drive. What about the combination of small internal and large external for the boot/system container?

 

[Brian33]

A standard install has multiple volumes inside the APFS container.

Yes, you're right, and I mis-spoke. I shouldn't have suggested breaking up the volumes within the APFS Volume Group (e.g, Preboot, Recovery, Data, VM).

I was thinking more that the "iBoot System Container" (type Apple_APFS_ISC, disk0s1 in my example of the standard setup below) and the Fallback Recovery (type Apple_APFS_Recovery, disk0s3) containers could (would, must) remain on the internal drive only, while the third "slice" of internal storage (disk0s2) could be combined with an external disk to create the single Fusion container. That Fusion container would have the Preboot, (paired) Recovery, Data, and VM volumes of the bootable system.

brian@mini4:~(0)$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: Apple_APFS_ISC Container disk1 524.3 MB disk0s1
2: Apple_APFS Container disk3 494.4 GB disk0s2
3: Apple_APFS_Recovery Container disk2 5.4 GB disk0s3

/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +494.4 GB disk3
Physical Store disk0s2
1: APFS Volume mini4-boot 11.2 GB disk3s1
2: APFS Snapshot com.apple.os.update-... 11.2 GB disk3s1s1
3: APFS Volume Preboot 13.7 GB disk3s2
4: APFS Volume Recovery 2.0 GB disk3s3
5: APFS Volume Data 153.9 GB disk3s5
6: APFS Volume VM 1.1 GB disk3s6

I note that the diskutil apfs createContainer command is what makes a Fusion container, so I suppose it would go something like
diskutil apfs createContainer -main disk0s2 -secondary disk4, where "disk4" is some external drive.

Maybe it could be done. Anyway, I think we agree that this is pure speculation until someone really tries it!

I am curious, though. Way back on El Capitan (I think), I was booting my iMac from a CoreStorage Fusion drive: internal 500GB SSD and an external 2TB HDD. It worked perfectly and it was so nice to be free of storage management hassles. With such a large (at the time) SSD portion, performance was excellent.

Many people now seem to immediately dismiss the idea of a Fusion drive because Apple messed up when they chose such a small SSD portion, resulting in some wearing out and failing. The idea/concept of tiered storage is still sound -- it was the specific implementation that was problematic. With my 500GB to 2TB proportions, I never had a problem (in fact, I still use that 2.5" SSD today). Today, really-fast internal storage fused with slower/cheaper external NVMe SSD could be useful, to keep iCloud content on the "boot" volume, presumably keep Apple Intelligence working, eliminating relocation of home directories or iPhotos libraries and other storage managment hassles.

My biggest worry would be whether macOS updates would mess it up or not, as an unsupported configuration.

 

[haravikk]

Do all the APFS volumes end up in the Fusion container or are some (e.g. VM, Recovery, Preboot) in an APFS container just on the internal SSD?

Recovery should be separate now, it will be created by the macOS installer if it's missing but you should try to avoid having to, I've updated the command to better reflect that. Though you do still end up with a recovery volume under the main container as well.

VM will end up in your Fusion container but that shouldn't affect anything, it just means that the page file(s) are tiered like everything else – if they're used frequently they'll stay on the main drive, otherwise parts of them may get migrated to the secondary drive instead.

 

[ChrisA]

I'm not interested in using a traditional HDD. My Mac Mini has 256GB internally, and I was thinking about getting a Thunderbolt external NVMe drive to try to increase my OS and Application partition. I could always just extend the OS partition across both drives, but I'm not sure if the Thunderbolt drive will run at the same speed as the internal drive (which can't be upgraded). I was thinking that doing the traditional Fusion Drive setup would handle moving the regularly used files to the internal storage for me.

You can buy an external SSD with the same performance as the internal. But not all external SSDs are that fast. I got mine from OWC. It comes with a cable, use that cable.

It is very easy to move stuff onto the new SSD. I use Unix calls "soft link" and what Apple calls
"alias" to move the larger folder to the external volume. It works transparently. I don't need to remember those folders are on the externals and the performance is the same.

 

[macnavarra]

I only see these model Mac Pro (2023) + included Apple SSD, 2 Options: 1st, boot in internet recovery open terminal give the following command: diskutil resetFusion, quit terminal install the suggested macOS.
Second option: boot with Usb Thumb drive and install Yosemite or El Capitan on Apple Fusion HDD, boot in internet recovery mode and install the suggested macOS on the Apple Fusion drive.

Option 1.
open terminal in boot mode csrutil disable boot...
open terminal sudo nvram boot-args="vm_compressor=2"
open terminal sudo trimforce enable
open terminal sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist
open terminal in boot mode : csrutil enable

Option 2.
open terminal in boot mode csrutil disable boot...
open terminal sudo nvram boot-args="vm_compressor=2"
open terminal sudo trimforce enable
open terminal sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist
Open terminal sudo rm /private/var/vm/swapfile*
open terminal in boot mode sudo launchctl load /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist
open terminal in boot mode : csrutil enable

 

[DaveFromCampbelltown]

Just reviving this thread, as I have had a bit more experience with creating an external Fusion drive for a Mac Mini, and booting from it.
Some of my earlier attempts weren't that successful, mostly because I was using older and/or under-powered drives.
The Mac Mini is a fast little beast, and it is a shame to throttle it with slow hardware.
I have found that this combination of hardware works well --

1. SSD. A good, 256 Gb SSD. I found that a Silicon Power P34A60 NVMe M.2 worked well. It certainly worked better than the Patriot P320 equivalent.
2. HDD. A good, fast hard drive. I found that having a 256 Mb Cache was important, as that helped the drive keep up with the SSD.

In general, I found it difficult to tell whether I was working from the internal SSD or from the Fusion drive. The one exception was dealing with large files stored on the HDD component of the Fusion drive, such as Virtual Machine files or installing a Mac OS System file. A Fusion drive is good for working with many smaller files (< 500Mb) rather than a fewer large files, such as Video files or VMware virtual machines. A good example is using LaTeX, compiling large text documents such as the text to Origin of Species, or the Bible. It was just as fast on the Fusion drive as it was on the internal SSD.

As ever, take backups.

 

[Simmalt]

I run a 2021 24" iMac M1 16/256 from the beginning with an home made FusionDrive.
Of the 256gb internal SSD, I have created a 200gb partition with the booting system, and beneath it, I have taken the resting 50gb to create a FusionDrive along with an external SSD Sabrent Rocket Nano (previously bought to be mounted with an adapter in a 2017 MacBook Pro A1708) of 2tb.
The external SSD is permanently connected to the iMac in a TB3 housing.
Things works good for about 3 years know, still I am dubious if it is a good idea.
Kind of fear of an abrupt corruption in the internal SSD which would make me losing everything (I nevertheless have a Time Machine backup in a 3gb Time Capsule).

 

[indiekiduk]

That is great info. For home server I was thinking of M4 Mac mini 256GB and using 64GB (or 128GB) fused with external 24TB HD. And putting home folder on it.

With an admin user on the main drive, if the external fails the Mac can still boot and be usable. And then maybe that is an easier situation to restore from a Time Machine of the whole thing (stored on a 2nd external).

 

[gilby101]

That is great info. For home server I was thinking of M4 Mac mini 256GB and using 64GB (or 128GB) fused with external 24TB HD. And putting home folder on it.

In my view, the 256GB is already minimal and I would not be willing to give up part of it to a Fusion Drive. Better to use a fast as possible external SSD which is large enough to include all your active files. I assume you also have an even larger HDD for your backups.

If you do put your home folder on a Fusion Drive, make sure 1) you have a good backup, and 2) have another admin user with its home folder on the boot volume.

 

[indiekiduk]

Yep 1 & 2 go without saying.

The problem with external ssd is it uses up another valuable port. Don’t you feel small part of internal 256 would be fine for fusing since the entire main users home folder will be fused?

Perhaps M4 mini is too overpowered for home server mostly for downloading and file serving. M1 has usb4 (eg into M.2 NVME adapter with M.2 NVME to mini SAS card for 4 bay mini SAS caddy) and is the lowest power consumption so might go with that.

 

[indiekiduk]

If the fusion is partition of internal SSD and an external. Does anyone know what happens if the exernal is plugged into another Mac? Is it useable? If not then this might be deal breaker.

Not even sure if partition of internal SSD is eligible for fusing or if it needs to be the entire disk. A partition ID is supplied to the fusion setup command so seems like it might be possible.

 

[indiekiduk]

In an interesting development, I found out if a part of the fusion is a RAID JBOD, you can add another phyical disk to the JBOD and then expand the APFS container to make use of the new space. It isn't normally possible to add a "Physical Store" to a container.

 

[Brian33]

If the fusion is partition of internal SSD and an external. Does anyone know what happens if the exernal is plugged into another Mac? Is it useable?

While I have not actually tried this, I am quite confident that it would NOT be usable. My understanding is that fusion drives work at the block level, not the file level. The most used blocks of data are on the high-speed portion. Files may be made up of many blocks; That implies that a given file may be spread between high-speed portion and the remainder of the fusion drive. Also, fusion drivesdo not work as a high-speed cache. That is, the blocks exist on either the high-speed portion, or the slow speed portion, and not on both.

Except for testing, I would not plug the external portion of a fusion drive into another computer, because I would worry that something could get written to that portion of the fusion Drive that could possibly mess up the fusion arrangement, possibly causing the loss of all files on the fusion drive. Again, it might be fun to test this idea out, just don’t do it with valuable files!

 

[DaveFromCampbelltown]

Fusion drives, once created, are one drive. You cannot plug one part or the other into another drive and see anything.

You can split either or both drives into two volumes and make fusion drives from the volumes.

Currently, the SSD component of the internal fusion drive on my iMac has failed, so I have built a fusion drive from an external SSD and the internal HDD. It's not as fast as the original drive, but I'm not going to pay hundreds of dollars to get my old iMac repaired.

 

[gilby101]

While I have not actually tried this, I am quite confident that it would NOT be usable.

Definitely unusable. It is file tiering technology, not a cache. The size of Fusion Drive is equal to sum of size of the two drives. Data exists on one or other component, not both.

My understanding is that fusion drives work at the block level, not the file level.

My understanding is somewhere in between. Basically it is file based, but moves chunks of large files back and forth. While I can mostly understand this for files, I am at a bit of a complete loss as to how it manages the file system structure (B-trees, folders, forks, attributes, etc.)

An early, but still accurate(?), description https://arstechnica.com/gadgets/2012/10/more-on-fusion-drive-how-it-works-and-how-to-roll-your-own/.

Edit: Someone who obviously understands a lot more about Fusion Drives than me (in particular with APFS): https://talk.tidbits.com/t/fusion-d...orth-it-or-perhaps-even-more-worth-it/17398/2

 

[Brian33]

My understanding is somewhere in between. Basically it is file based, but moves chunks of large files back and forth. While I can mostly understand this for files, I am at a bit of a complete loss as to how it manages the file system structure (B-trees, folders, forks, attributes, etc.)

Well, I thought I had read that the the older CoreStorage (HFS+) Fusion drives moved files but that the newer (APFS) system moved blocks, but I can't find any references for that at the moment. However, if by moving "chunks of large files" means moving portions of files (not complete files), then to me that seems the same as moving (some number) of blocks. So we basically agree?

It's an interesting question, though off the top of my head I can't think of any way to empirically test whether entire files are moved or portions of files.

Edit: Someone who obviously understands a lot more about Fusion Drives than me (in particular with APFS): https://talk.tidbits.com/t/fusion-d...orth-it-or-perhaps-even-more-worth-it/17398/2

Huh. In that posting, the author claims that while the usable size of a CoreStorage Fusion drive (actually, volume) is the sum of the components' sizes, he claims the usable size of an APFS Fusion volume is only equal to the size of the (presumably larger) "HDD" portion, and that the SSD only acts as a cache, and that all of the files exist on the "HDD" portion. I.e., it's a cached storage system but not tiered storage.

I'm highly skeptical of that. I'll try to throw together an APFS fusion drive and at least see what the usable capacity is...

 

[DaveFromCampbelltown]

...
Huh. In that posting, the author claims that while the usable size of a CoreStorage Fusion drive (actually, volume) is the sum of the components' sizes, he claims the usable size of an APFS Fusion volume is only equal to the size of the (presumably larger) "HDD" portion, and that the SSD only acts as a cache, and that all of the files exist on the "HDD" portion. I.e., it's a cached storage system but not tiered storage.

I'm highly skeptical of that. I'll try to throw together an APFS fusion drive and at least see what the usable capacity is...

You are right. Even with APFS, the size of the drive is the combined size of the two drives.
I am currently running a Fusion drive made up of a 256Gb SSD and a 2Tb HDD.
This is the listing from diskutil.

/dev/disk6 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk6
   1:                        EFI EFI                     209.7 MB   disk6s1
   2:                 Apple_APFS Container disk8         2.0 TB     disk6s2

/dev/disk7 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *256.1 GB   disk7
   1:                        EFI EFI                     209.7 MB   disk7s1
   2:                 Apple_APFS Container disk8         255.9 GB   disk7s2

/dev/disk8 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.3 TB     disk8
                                 Physical Stores disk7s2, disk6s2
   1:                APFS Volume Fusion - Data           303.8 GB   disk8s1
   2:                APFS Volume Fusion                  11.2 GB    disk8s2
   3:              APFS Snapshot com.apple.os.update-... 11.2 GB    disk8s2s1
   4:                APFS Volume Preboot                 8.2 GB     disk8s3
   5:                APFS Volume Recovery                2.0 GB     disk8s4
   6:                APFS Volume VM                      20.5 KB    disk8s5

You can see that the size of the drive is 2.3 Tb, the sum of the two component drives.

Files live on either the SSD component or the HDD component. This is more complicated for Applications, which are a bundle of a series of files.

You can see which drive is being access using the iostat command. The following is a listing of the activity of the two components of my Fusion drive when loading three large applications (LibreOffice, MS Word and WPS Office).
The left hand columns are the SSD and the right hand columns are the HDD. You can see that most of the activity is from the SSD, i.e. the applications are being loaded from that component.

      disk7 (SSD)         disk6 (HDD)
    KB/t  tps  MB/s     KB/t  tps  MB/s
    4.00    0  0.00     4.00    0  0.00
   24.72  132  3.19    16.00    2  0.04
   32.77 2272 72.72    28.14   74  2.03
   73.96 1023 73.87    28.19  113  3.12
   26.15 2195 56.05    48.62   99  4.72
   60.18  906 53.25    33.01   95  3.07
   39.90 1506 58.70    42.78   92  3.84
   62.08 1741 105.56    30.97  169  5.11
   21.86 1370 29.25    37.90  393 14.55
    4.82  211  0.99    10.67    1  0.02

 

[chown33]

It's an interesting question, though off the top of my head I can't think of any way to empirically test whether entire files are moved or portions of files.

The Ars Technica article linked above mentions some tests that involve reading the first sections of large files, and measuring the speed at which data is returned. Search for the word "redirected" in the article. It's that paragraph and the subsequent one.

 

[gilby101]

However, if by moving "chunks of large files" means moving portions of files (not complete files), then to me that seems the same as moving (some number) of blocks. So we basically agree?

I don't quite agree, but let's not get tangled up in splitting hairs!

Huh. In that posting, the author claims that while the usable size of a CoreStorage Fusion drive (actually, volume) is the sum of the components' sizes, he claims the usable size of an APFS Fusion volume is only equal to the size of the (presumably larger) "HDD" portion, and that the SSD only acts as a cache, and that all of the files exist on the "HDD" portion. I.e., it's a cached storage system but not tiered storage.

I'm highly skeptical of that. I'll try to throw together an APFS fusion drive and at least see what the usable capacity is..

I also am sceptical.

But it is clear that Fusion with APFS is subtly different to Fusion with HFS+. Something that I had not appreciated.

Howard Oakley discusses it here https://eclecticlight.co/2018/10/15/fusion-drives-in-apfs/ and shows the size of the APFS container to be the sum of the two parts. But can you use that full size?

And more recently from Howard: https://eclecticlight.co/2024/04/26/was-the-fusion-drive-a-good-idea/. I think I am correctly summarising that as: It was great, but now don't.

You can see that the size of the drive is 2.3 Tb, the sum of the two component drives.

Can you fill it with nearly 2.3 TB of data? (I am hoping the answer is yes)

 

[DaveFromCampbelltown]

I don't quite agree, but let's not get tangled up in splitting hairs!


I also am sceptical.

But it is clear that Fusion with APFS is subtly different to Fusion with HFS+. Something that I had not appreciated.

Howard Oakley discusses it here https://eclecticlight.co/2018/10/15/fusion-drives-in-apfs/ and shows the size of the APFS container to be the sum of the two parts. But can you use that full size?

And more recently from Howard: https://eclecticlight.co/2024/04/26/was-the-fusion-drive-a-good-idea/. I think I am correctly summarising that as: It was great, but now don't.


Can you fill it with nearly 2.3 TB of data? (I am hoping the answer is yes)

I haven't tried. Even the full collections of Dr Who would only take up about 500 Gb. Project Gutenberg in Zim format is only 67 Gb.

 

[gilby101]

Can you fill it with nearly 2.3 TB of data? (I am hoping the answer is yes)

I haven't tried. Even the full collections of Dr Who would only take up about 500 Gb. Project Gutenberg in Zim format is only 67 Gb.

Seems the answer is no. Surprise for me, though maybe not for others elsewhere.

I created two virtual disks in a VMware Sequoia client (I don't have spare drives lying around). In VMware they are 10GB and 60GB (base2?). In macOS they are 10.7 GB and 64.4 GB (base 10?). Made a Fusion Drive APFS container of 75.2 GB with one APFS volume.

I copied files (RAW photos and XMP files) onto it. I could only get as far as 64.4 GB before the drive became full. So can only get as far as filling the secondary storage.

For info, my steps and abbeviated diskutil lists are:
Two unformatted drives:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *10.7 GB disk0
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *64.4 GB disk1
Create Fusion container:
% diskutil apfs createContainer -main disk0 -secondary disk1
/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +75.2 GB disk6
Physical Stores disk0, disk1
Create APFS volume:
% diskutil apfs addVolume disk6 APFS MyFusionDrive
/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +75.2 GB disk6
Physical Stores disk0, disk1
1: APFS Volume MyFusionDrive 868.4 KB disk6s1
And fill it up:
/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +75.2 GB disk6
Physical Stores disk0, disk1
1: APFS Volume MyFusionDrive 64.4 GB disk6s1

The MyFusionDrive now occupies the same space as just the secondary drive (64.4 GB).

Disk Utility now says:
Volume size: 75.16 GB
Used: 64.4 GB
Other: 2.28GB (what other??)
Free: 8.46 GB

The "Other" is not mentioned even in
% diskutil apfs list
+-- Container disk6 70B0B252-FAA9-4EC6-ABBE-BEA3F6F38BF2
====================================================
APFS Container Reference: disk6 (Fusion)
Size (Capacity Ceiling): 75161927680 B (75.2 GB)
Capacity In Use By Volumes: 66706821120 B (66.7 GB) (88.8% used)
Capacity Not Allocated: 8455106560 B (8.5 GB) (11.2% free)
|
+-< Physical Store disk1 (No UUID)
| ------------------------------
| APFS Physical Store Disk: disk1 (Secondary, Designated Aux Use)
| Size: 64424509440 B (64.4 GB)
|
+-< Physical Store disk0 (No UUID)
| ------------------------------
| APFS Physical Store Disk: disk0 (Main, "Faster" Disk Use)
| Size: 10737418240 B (10.7 GB)
|
+-> Volume disk6s1 C66C6360-1242-4A3C-B817-078E7ADCEE3B
---------------------------------------------------
APFS Volume Disk (Role): disk6s1 (No specific role)
Name: MyFusionDrive (Case-insensitive)
Mount Point: /Volumes/MyFusionDrive
Capacity Consumed: 64429219840 B (64.4 GB)
Sealed: No
FileVault: No


I don't think this proves or disproves either cache or "smeared between both" storage though it is very suggestive of cache.

In the comments to https://eclecticlight.co/2024/04/26/was-the-fusion-drive-a-good-idea/ Howard says "Well, I think you’ll find that APFS uses the SSD component in a caching strategy, unlike CoreStorage that tried to be smarter than that."

Huh. In that posting, the author claims that while the usable size of a CoreStorage Fusion drive (actually, volume) is the sum of the components' sizes, he claims the usable size of an APFS Fusion volume is only equal to the size of the (presumably larger) "HDD" portion, and that the SSD only acts as a cache, and that all of the files exist on the "HDD" portion. I.e., it's a cached storage system but not tiered storage.

I'm highly skeptical of that. I'll try to throw together an APFS fusion drive and at least see what the usable capacity is...

I am coming round to it being a cache in APFS Fusion Drive. Certainly my experiment confirms size of volume is sum of primary + secondary, but the usable size is that of the secondary.

 

[Brian33]

Thank you @gilby101 ! That was a really interesting post, and really opened my eyes! I'd been assuming Fusion under APFS would be similar to Fusion under CoreStorage (HFS+).

I created two virtual disks in a VMware Sequoia client (I don't have spare drives lying around). In VMware they are 10GB and 60GB (base2?). In macOS they are 10.7 GB and 64.4 GB (base 10?). Made a Fusion Drive APFS container of 75.2 GB with one APFS volume.

I copied files (RAW photos and XMP files) onto it. I could only get as far as 64.4 GB before the drive became full. So can only get as far as filling the secondary storage.

I'm honestly rather shocked at the apparent difference in the designs of Fusion drives for APFS vs. HFS+! I was so impressed with Fusion under CoreStorage (HFS+) as a form of tiered storage -- its nerdy "coolness" as well as its effectiveness and efficiency with large primary (fast SSD) portions. For a long time I booted from a 0.5GB + 2GB CoreStorage Fusion drive. And now with APFS we can't even use the total combined storage space? Terrible.

I don't think this proves or disproves either cache or "smeared between both" storage though it is very suggestive of cache.

I am coming round to it being a cache in APFS Fusion Drive. Certainly my experiment confirms size of volume is sum of primary + secondary, but the usable size is that of the secondary.

Yes, I agree it strongly suggests that APFS Fusion setups just use the primary partition as cache. Ugh! But we really don't know HOW macOS is using it, just that it seems to be unavailable to the user (unlike a CoreStorage Fusion drive -- at least I used to believe!). Is it plausible that it's still working like tiered storage, but some bugs are preventing the user from writing to (what "should" be) the ultimate capacity? I wonder what's more likely, a major change in design, or a few bugs?

In the old CoreStorage HFS+ Fusion drives I experimented with, I was able to use something llike 'iostat -w 1 -d disk4 disk5' where disk4 and disk5 were the two components of the Fusion drive. This allowed me to see the "fast" component fill up with data, then overflow to the slow component. Then during a pause in writing, to see 4GB of data move from fast to slow to open up a 4 GB buffer on the fast component. Then further writing always going to the fast component, and further pauses showing clearing of the buffer. Thus I could sort of see the operation and it convinced me my DIY fusion drive was "working." (I assumed at the time, but didn't test, that I could fill the entire fast capacity + slow capacity.)

However, it seems that same pattern of behavior would still emerge even if the fast component was only being used as a cache and didn't "permanently" store any files, so it doesn't prove one way or the other. Hmmm. I don't have nearly enough knowledge/programming skill to figure out on which device a file's extents are actually stored. It seems like it could be possible to do at the API programming level, though.

I'm really disappointed if the APFS fusion drive really took (IMHO) a big backward step. It sure does look like it, though. : ( It's not that I NEED a Fusion drive. Mostly I thought the idea, and making it available to the user, was technically cool. And it could have been extended easily. For example, imagine a Fusion volume composed of: RAM-->internal SSD-->external SSD-->external HDD, all working perfectly and hidden from the user.

Again, @gilby101, thanks for the data point.

 

[gilby101]

I have done a bit more with Fusion drives in a VM and have managed to get a VM booting from an APFS Fusion Drive.

This is for Intel, not Apple silicon.

In my earlier post I created a Fusion Drive from two virtual disks. This was a Fusion Drive in addition to a system/boot disk. I have since attempted a new VM with just a Fusion Drive. But booting from a Fusion Drive built as before fails mid macOS instal. I think this is due to using "raw" unpartitioned disks to create the Fusion Drive. There was no EFI partition to start an Intel macOS boot sequence.

So I partitioned the two "raw" disks with an exFAT partition. I am sure the format does not matter, the important thing is for there to be an EFI partition which can enable the boot sequence.

With that done the create container step is now:

% diskutil apfs createContainer -main disk1s2 -secondary disk0s2

After completing the macO install I have:

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *85.9 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 85.7 GB disk0s2
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *21.5 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_APFS Container disk2 21.3 GB disk1s2
/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +107.0 GB disk2
Physical Stores disk1s2, disk0s2
1: APFS Volume Macintosh HD — Data 5.8 GB disk2s1
2: APFS Volume Preboot 2.4 GB disk2s2
3: APFS Volume Recovery 1.3 GB disk2s3
4: APFS Volume Macintosh HD 11.2 GB disk2s4
5: APFS Snapshot com.apple.os.update-... 11.2 GB disk2s4s1
6: APFS Volume VM 1.1 MB disk2s6

Note that all the expected APFS volumes are inside the APFS Fusion disk.

This can boot successfully because there are EFI partitions. This VM (build in VMware) reflects an Intel Mac without T1 or T2 chips. I am sure this would also work with equivalent real hardware (e.g. iMac up to 2019). I don't know if it would work with the last generations of Intel Macs with the T1 or T2 security/boot chip.

Sadly (the real point of this thread): This does not show that Apple silicon Macs (M1/2/3/4) can boot from a Fusion Drive. I don't have the spare hardware to attempt this and an Apple silicon VM is not sufficiently equivalent to real hardware.