hoakley March 11, 2024 Macs, Technology

iCloud Drive in Sonoma: Optimise Mac Storage or not?

There are two fundamental controls for iCloud Drive: whether to Optimise Mac Storage, and whether to put Desktop & Documents Folders into iCloud Drive. This is the first of two articles that looks at what each does, and how it works. This starts with the simpler choice, based on whether you want iCloud Drive and your Mac’s local copies of files to remain in sync at all times.

Prior to Sonoma, the Optimise Mac Storage control made little if any difference to the behaviour of iCloud Drive. Regardless of the chosen setting, both the user and macOS were able to remove files from local storage, a process known as eviction. For several years, this wasn’t easy in the Finder, as there was no accessible control to evict files, although this was a major feature in my free app Cirrus and its menu bar companion Bailiff (no longer supported).

At that time, eviction replaced the local file with a hidden stub file containing a reference to the complete copy held in iCloud Drive. Any attempt to open the local file then resulted in the download of the file’s data, a process now known as materialisation.

Sonoma changed this for a new system based on a FileProvider mechanism, as used by third-party cloud services. This operates in either of two modes:

replicating, with Optimise Mac Storage turned off, where local and remote iCloud Drive folders and files should remain identical, and eviction isn’t allowed;
non-replicating, with Optimise Mac Storage turned on, where local files can be evicted and rendered dataless, and only iCloud Drive holds all the files complete with their data.

The most critical phase is the transition between those two modes, when the Optimise Mac Storage setting is changed.

Turn Optimise Mac Storage on

After a few seconds, the control turns itself off again, and needs to be turned on a second time for the new setting to stick. It’s unclear why that should occur, or whether it affects what happens. There should be no immediate effect on file storage, as in the previous state local and remote files should have formed a perfect mirror, and none could have been evicted.

Changing the setting is first reported by bird, which then triggers FileProvider to iterate through all items in iCloud Drive setting them to be evictable, with a great many log entries of the form
✍️ FS snapshot mutation: update<s:fileID(674133) […] diffs:evictable why:item changed ✍️ persist job: <J2 ⏳ update-item(propagated:[…] diffs:evictable) why:itemChangedRemotely sched:background#1709468042.083435 ⧗persisted> ┳15d1e ✅ done executing <J2 ✅ update-item(propagated:[…] diffs:evictable) why:itemChangedRemotely […] [duration 106ms634µs]
and covering both local and remote (FP and FS) directory trees.

There’s additional housekeeping to be performed on local property lists for the different domains, which include a separate domain for shared Photos libraries, as revealed in log entries such as
[NOTICE] ┏158b5 writing domain properties for com.apple.CloudDocs.MobileDocumentsFileProvider onto […] [NOTICE] ┏158d0 writing domain properties for com.apple.Photos.PhotosFileProvider onto […] [NOTICE] ┏158da writing domain properties for com.apple.CloudDocs.iCloudDriveFileProvider onto […] [NOTICE] ┏158de Updating list of extensions [NOTICE] ┏158df Listing domains & providers in <AppSupport>/FileProvider [NOTICE] ┏158e0 Listing domains & providers in […]

Early snapshot mutations are followed by container patching, such as
Patching container <FPFSItem 0x15002a560:__fp/fs/fileID(691051) (replacing:a52) l:"S{7}s" container bid:com.apple.shortcuts […]> with <FPFSItem […] ul:uploaded dl:current rec-dl:yes>

As there are no files to be materialised, the process of change is determined by the number of items in iCloud Drive, and shouldn’t normally require any syncing of file data. That said, in early versions of Sonoma, and macOS that had only been recently upgraded, some users have reported long syncing as a result. When it works properly, turning Optimise Mac Storage on should be an administrative task for FileProvider, and accomplished quickly.

Turn Optimise Mac Storage off

The control behaves similarly, turning itself back on after a few seconds, and has to be returned to off a second time. This has a similar effect on FileProvider, which iterates through the entire contents of iCloud Drive changing the evictable property of all folders and files. However, this also requires the materialisation (download) of all files and folders that are currently evicted.

One distinctive log entry announces the background download:
[NOTICE] ⏱ com.apple.fileproviderd.background-download: new watcher registered for c{60}) following which FileProvider iterates through all items inn iCloud Drive removing the evictable property, in entries such as ✍️ FS snapshot mutation: update<s:fileID(690953) […] diffs:evictable why:item changed ✍️ persist job: <J1 ⏳ update-item(propagated:[…] diffs:evictable) why:itemChangedRemotely sched:background#1709453882.838437 ⧗persisted> ┳1021 ✅ done executing <J1 ✅ update-item(propagated:[…] diffs:evictable) why:itemChangedRemotely […] [duration 8ms30µs]

icdOMSoff1

This early torrent of log entries is accompanied by the download and materialisation of all evicted items, which can take a long time. You should see a progress window reporting the amount of downloaded data. Thus the time required to complete this sync is largely determined by both the number of items stored in iCloud Drive and the total amount of data that must be downloaded to materialise all evicted files. Some early adopters reported an initial sync of the entire contents of their iCloud Drive, but that isn’t required and shouldn’t happen now.

icdOMSoff2

Storage debt

The only real danger of running with Optimise Mac Storage turned on is that the total space occupied by data from evicted files can come to exceed the total free space on that Mac. In that case, turning it off again won’t work, as there’s insufficient local free space to accommodate all the materialised files.

For instance, if the total original size of the files that are now evicted is 1 TB, but that Mac has only 100 GB free on its internal SSD, then there isn’t sufficient room to turn Optimise Mac Storage off again. In the short term, many of those files must remain stored in iCloud Drive, and only some of them could be downloaded into local storage. That in turn has the disadvantage that those evicted files are no longer available for backup or Spotlight search.

There doesn’t appear to be any simple way to determine whether your Mac has entered storage debt. If you use Get Info on the iCloud Drive location, the total size reported may represent that currently in use by locally stored files. Comparing that with the size given for the Documents category in the bar chart at the top of iCloud settings may give an idea of the total that would be required if all evicted files were to be downloaded, but it’s not clear how accurate that would be in practice.

Summary

When Optimise Mac Storage is on, that sets iCloud Drive into non-replicated mode, allowing both the user and macOS to evict files and folders from local storage.
When Optimise Mac Storage is off, iCloud Drive runs in replicated mode, no eviction is possible, but local and remote files are synced to remain identical.
Turning Optimise Mac Storage on requires settings on every file in iCloud Drive to be changed, and the time required is proportional to the total number of files in iCloud Drive. Provided that you have already upgraded iCloud Drive to Sonoma, this shouldn’t require any downloads or uploads, and should complete relatively quickly.
Turning Optimise Mac Storage off not only requires settings on every file in iCloud Drive to be changed, but also requires the download of all evicted files to local storage. It will thus take significantly longer, and the greater the total size of evicted files, the longer it will take. In some cases, that could be many hours, even if you have already upgraded iCloud Drive to Sonoma.
Storage debt can occur when Optimise Mac Storage is turned on, if the total size of evicted files exceeds free space on your Mac. If that’s the case, then you won’t be able to turn it off, and will have to keep some files evicted, where they can’t be backed up locally or searched by Spotlight.
As it doesn’t appear easy to get an accurate estimate for the total size that would be required to accommodate the download of all evicted files, it’s not easy to know whether your Mac has entered storage debt.

37Comments

Add yours

1

John Woods on March 11, 2024 at 8:52 am
Reply

I think it’s a messy UX. what if it’s off on Mac A, then some other Mac B adds a gargantuan file that A cannot handle, now we have it off on A, but without eviction available, yet one file will be naturally evicted. Messy.

LikeLiked by 1 person
- 2
  
  hoakley on March 11, 2024 at 9:24 am
  Reply
  
  Well, if you don’t have the option of using a non-replicating File Provider on either Mac, that’s even worse. I suspect that Mac B wouldn’t be able to add that file to the cloud.
  Taking your example and adding a little more detail:
  You have a capacious Mac Studio with ample free space on its internal SSD, that you operate with OMS turned off, as a replicating FileProvider. On that, you add a 10 GB file to iCloud Drive. That syncs up, and everything is fine there.
  On your MacBook Air, you only have a small internal SSD that has less than 50 GB free space. If that too is only able to run as a replicating FileProvider, that 10 GB file must sync down to it, and you can’t evict it once it’s there. You then have insufficient free space to update macOS, and the only way to rectify that is to delete files from your iCloud Drive. So you turn OMS on, to make it non-replicating, evict the 10 GB file, and lo and behold you can now update macOS *and* have that 10 GB file in iCloud Drive, at the same time.
  Is that messy or flexible?
  Howard.
  
  LikeLike
- 3
  
  hoakley on March 11, 2024 at 9:28 am
  Reply
  
  Note that a replicating FileProvider *can’t* evict files from its local storage, neither by the user’s choice, nor by that of macOS. In Sonoma, no eviction is possible if it’s replicated, as the word should imply.
  Howard.
  
  LikeLike
  - 4
    
    John Woods on March 11, 2024 at 9:33 am
    Reply
    
    your example was flexible, but it’s messy in the example where the file isn’t 10gb but 100gb. What then?
    
    Mac A can’t replicate and the file is essentially evicted.
    
    LikeLiked by 1 person
    - 5
      
      hoakley on March 11, 2024 at 9:40 am
      
      Well, you can’t store a 100 GB file in iCloud Drive anyway, but assuming that it was less than the limit of 50 GB but still larger than the free space on that Mac, I think that would result in an iCloud Drive error. But there’s no way out of that situation if you can’t opt for non-replication, is there?
      Recall that eviction isn’t the absence of the file, it means that the file becomes dataless. I think in your case, even that wouldn’t happen, the file would simply not exist on that Mac. But I’ll leave that to someone else to test 🙂
      Howard.
      
      LikeLike
    - 6
      
      hoakley on March 11, 2024 at 9:55 am
      
      More:
      Apple currently offers a maximum quota of 12 TB of iCloud+ storage. As no Mac currently can have an internal SSD larger than 8 TB, how could anyone ever use 12 TB?
      Indeed, let’s say your desktop Mac uses much of your 2 TB quota for iCloud Drive. That would mean that no other Mac of yours could connect to iCloud Drive unless it was able to accommodate more than 1 TB of replicated files from iCloud Drive.
      OMS might appear complicated, but it’s essential for many users.
      Howard.
      
      LikeLike
  - 7
    
    John Woods on March 11, 2024 at 3:02 pm
    Reply
    
    I agree. I think OMS is essential. For 12GB of cloud and any normal computer OMS is the only option that makes sense.
    
    LikeLiked by 1 person
8

jimgbuffalo on March 11, 2024 at 1:14 pm
Reply

Applying what I heretofore considered to be common sense, I have “Optimize Mac Storage” toggled off and yet use iCloud drive for manual drag-and-drop remote storage. The local files disappear upon upload, which I verify by searching with Find Any File as well as monitoring free space. What am I missing?

LikeLiked by 2 people
- 9
  
  hoakley on March 11, 2024 at 1:27 pm
  Reply
  
  But they don’t disappear at all, do they? You can see them in your iCloud Drive location. But what you see there is actually what is still stored on your Mac (and mirrored in iCloud Drive).
  It’s easy to confirm that using my app Precize, which shows the inode number of files. Before you ‘move’ the file to iCloud Drive, drop it onto Precize and make a note of its volfs path (easily copied using Command-2), the last number in which is its inode number. Then, when it’s in iCloud Drive, do the same with that file and you’ll see it’s exactly the same. It hasn’t moved off that volume at all – it’s all an illusion.
  Howard.
  
  LikeLike
  - 10
    
    jimgbuffalo on March 11, 2024 at 3:35 pm
    Reply
    
    OK. I think I had naively believed iCloud Drive was simply a remote drive. So I have re-enabled Optimize Storage, which I take to be the setting necessary to remotely store data on iCloud Drive and consequently free up local space. It appears that the files I thought I had previously deleted locally are now actually deleted - I seem to have reclaimed the commensurate space on my internal SSD (approx. 200 GB of non-essential media files). Apple is so very clever, perhaps someone in Cupertino was awarded a Genius designation for this exceedingly opaque design implementation (opacity in this context is a virtue).
    
    LikeLiked by 1 person
    - 11
      
      hoakley on March 11, 2024 at 5:10 pm
      
      iCloud Drive is a remote storage system. However, most users want immediate access to many of the files they store there, so the locally stored originals are normally kept for that purpose.
      There are two options as to how this works:
      – with OMS turned off, your local files and those in iCloud Drive are kept in sync, and complete, at all times
      – with OMS turned on, your local files and those in iCloud Drive are kept in sync, but you (and macOS) can decide whether you want to discard the local copy of the file’s data, a process known as eviction. If you and macOS never evict a file, then this is essentially the same as with OMS turned off, but that would lose the ability for files to be evicted.
      Eviction doesn’t delete any files locally, but it simply removes their data. The rest of the file still exists, and can be seen in iCloud Drive. However, if you want to access that evicted file, that data has to be downloaded from iCloud Drive before you can do so.
      Two substantial disadvantages to evicting files are that they can’t be backed up by Time Machine while they’re evicted (as their data isn’t stored locally any more), and they can’t be searched by Spotlight (as their contents aren’t locally accessible).
      I hope that helps make this all clearer. It really is quite simple.
      Howard.
      
      LikeLike
    - 12
      
      jimgbuffalo on March 12, 2024 at 1:20 pm
      
      Thank you for your comments, Howard. I believe my problem is being mentally stuck on the old school concept of an external drive which I manage manually, copy or delete. iCloud Drive adds new layers of complexity I have found perplexing. It’s not so easy to evict one’s thoughts!
      
      LikeLiked by 1 person
    - 13
      
      hoakley on March 12, 2024 at 9:03 pm
      
      No problems. I will try to paint an even clearer picture in a future article.
      Howard.
      
      LikeLike
14
hstriepe on March 11, 2024 at 2:58 pm
Reply
Given iCloud has been around I am surprised that Apple has not given it a rounded out design. You should be able to give it local storage pool size targets letting it work in a hybrid mode.

Something like this mght work:
- As long as the total of your file is below the pool size, it’s like optimize is off.
- When you reach pool size optimize turns it on.
- If you lower the pool size, it starts evicting, if the limit is exceeded
- In the default automatic mode it would allocate a percentage of the free disk size of the volume the home folder.
- A simple indicator would show state.
LikeLiked by 1 person
- 15
  
  hoakley on March 11, 2024 at 3:12 pm
  Reply
  
  Why? What is this a hybrid of?
  Putting files in iCloud Drive doesn’t change the amount of storage space required locally. Why apply complicated pools to change behaviour? For most users, this is a simple decision: do I want iCloud Drive to mirror what’s stored in my Home folder, or do I want to be able to have just some of those files taking space on my Mac?
  macOS will evict files automatically when Optimise Mac Storage is turned on. They’re marked as being purgeable, and can be purged when local free space falls, typically below 20 GB. If you want to manage that yourself, then all you have to do is evict files you don’t need to be stored locally as well.
  I can’t see any benefit in making the system so complicated most users wouldn’t understand it.
  Howard.
  
  LikeLike
  - 16
    
    hstriepe on March 11, 2024 at 3:13 pm
    Reply
    
    This is a solution for multiple systems. My desktops have a huge amount of space, my MacBooks do not.
    
    LikeLiked by 1 person
    - 17
      
      hoakley on March 11, 2024 at 3:17 pm
      
      So you turn Optimise Mac Storage on for your notebooks.
      That’s all you need to do. Then you decide which files are stored locally on them, and which are evicted. Adjust until they have as much free space as you want them to have. Much better than macOS deciding to evict files you want to keep stored locally, just because some arbitrary pool size threshold was exceeded.
      Howard.
      
      LikeLike
    - 18
      
      hstriepe on March 11, 2024 at 3:23 pm
      
      The problem with jsut optmize is that I have had it run away and take more than I like. Then I have to fiddle around with eviction. On one of my systems I was suddnely down to less than 100GB. I want at least 20% of the disk free.
      I simply prefer more control.
      
      LikeLiked by 1 person
19

hstriepe on March 11, 2024 at 3:25 pm
Reply

All of that is not an issue on my Studio with 4TB system disk and 10TB external drives, were media, VMs etc. are on Thunderbolt drives and the system and home folder only use 50% of the disk.

LikeLike
20

hstriepe on March 11, 2024 at 3:27 pm
Reply

BTW, I would always have ONE source were there is no optimization. The same is true for Photos or Music.

Trust no one (service.)

LikeLiked by 1 person
- 21
  
  hoakley on March 11, 2024 at 5:14 pm
  Reply
  
  That’s really simple: your Studio has OMS turned off, to use iCloud Drive as a replicating File Provider; your MBPs have OMS turned on, to use it as a non-replicating File Provider.
  You then manage the iCloud Drive folders on your MBPs, evicting folders and files from them that you don’t want immediate access to. This is easy to do by bringing up the Finder’s contextual menu, and using the Remove download command there. You can use that on the whole of iCloud Drive if you really need to free up space quickly, e.g. for a large macOS update. That gives you the control you need, rather than cursing macOS for not getting it right, and evicting the wrong files at the wrong time.
  Howard.
  
  LikeLike
22

Duncan on March 11, 2024 at 4:19 pm
Reply

This whole ‘eviction/materialize’ scheme seems pretty risky in my mind. Lots of bits traveling to and fro over a quasi-reliable connection. This is yet one more reason why Apple should implement bulletproof file integrity in their file system. And they already know how to do it (on their Signed System Volume), so what’s holding them back?

LikeLiked by 1 person
- 23
  
  hoakley on March 11, 2024 at 5:02 pm
  Reply
  
  Trust me, Duncan, you really, really don’t want the same tree of cryptographic hashes used in the SSV on all your Mac’s volumes, let alone iCloud Drive. However, Apple doesn’t entirely disregard this. We don’t know what integrity checking might take place in iCloud itself, but transfers between your Mac and iCloud Drive use hashes on their file chunks to guarantee their integrity.
  I’ve been running a long-term check on iCloud Drive for nearly 4 years now, with 97 images and similar files stored there, and tagged using Dintch. Prompted by your comment, I ran one of my periodic checks, and all 97 are not only still there, but match their original hashes.
  Howard.
  
  LikeLike
  - 24
    
    Duncan on March 11, 2024 at 5:14 pm
    Reply
    
    Thank you. I guess I should have clarified – I wasn’t suggesting the full cryptographic hash tree of the SSV but just integrity checks at the individual files level, similar to your Dintch utility. If Apple is indeed using hashes for the file transfers, then why stop there?
    
    (As you can guess, I really want this to become a built-in file system feature once and for all.)
    
    LikeLike
    - 25
      
      hoakley on March 11, 2024 at 5:17 pm
      
      I agree completely with you. My hope is that as slower, older Intel Macs drop out of current macOS, this is the sort of feature that Apple will feel is appropriate for the power of M-series chips. Perhaps we should start filing Feedbacks in readiness?
      Howard.
      
      LikeLike
    - 26
      
      Duncan on March 11, 2024 at 5:21 pm
      
      It looks like you had a transmission glitch at the beginning of your comment. 🙃
      
      (And yes, I’m also hoping that this will become an M-series feature once MacOS leaves Intel behind, which might be in another year or two.)
      
      LikeLiked by 1 person
    - 27
      
      hoakley on March 11, 2024 at 5:23 pm
      
      Thanks, just the standard Apple Magic stutter 🙂
      Howard.
      
      LikeLike
    - 28
      
      Duncan on March 11, 2024 at 5:25 pm
      
      Hey – you fixed the typo and spoiled my joke. Everyone else will read this and wonder what I’m going on about. (Same as always, I suppose.)
      
      LikeLiked by 1 person
29

mikebhm on March 11, 2024 at 6:40 pm
Reply

Picking up on the issue mentioned by @hstriepe in post 16, do you know what criteria macOS uses to define “enough free space” if left to its own devices. And when it determines that there is not enough space how does it decide what to evict first? Thanks.

LikeLiked by 1 person
- 30
  
  hoakley on March 11, 2024 at 7:09 pm
  Reply
  
  Good questions, but no answers, I’m afraid.
  Normally, evictable iCloud Drive files would be considered to be purgeable space, and they’re referred to in iCloud as being purgeable. However, as I’ve explained, as far as the purgeable space listed by macOS, that doesn’t include any that might be recovered by evicting files in iCloud Drive. That’s not hard to verify.
  So, what triggers macOS to evict files of its own accord? Although quite a few files in my iCloud Drive have been evicted by macOS and not me, they’ve never been evicted on grounds of insufficient free space. So the dominant reason for eviction by macOS appears to be as a result of the files not being accessed for a long time, like old tax records in my case.
  I’ve been unable to find any information about this from Apple, unsurprisingly. I can’t test it out in a VM, which would be an ideal experimental model, as lightweight macOS VMs can’t use Apple ID or iCloud Drive. Although I must had read tens or hundreds of thousands of log entries and property lists concerning iCloud Drive and FileProvider, I’ve never come across anything of relevance.
  It’s at this point that I hand over to someone else to work this out – I’m done, I’m afraid!
  Howard.
  
  LikeLike
  - 31
    
    mikebhm on March 11, 2024 at 7:15 pm
    Reply
    
    Thanks Howard. The only thing I can contribute is that like @hstriepe macOS is will to use up more space than I want it to. This applies to optimise in Photos libs as well.
    
    LikeLiked by 1 person
    - 32
      
      hoakley on March 11, 2024 at 7:40 pm
      
      That’s what OMS and eviction are for.
      Howard.
      
      LikeLike
33

mikebhm on March 11, 2024 at 7:58 pm
Reply

Yes indeed but to keep more free space than macOS chooses is a manual process of eviction as @hstriepe said. Maybe there is an Enhancement Request here to specify minimum free space, like reserve and quota sizes for APFS space sharing volumes?

LikeLiked by 1 person
- 34
  
  hoakley on March 11, 2024 at 8:00 pm
  Reply
  
  Why leave it to macOS to decide when it’s so easy to manage yourself? After all, you do the rest of the free space management perfectly well.
  Howard
  
  LikeLike
35

WA2FLQ on March 12, 2024 at 3:21 am
Reply

This posting/discussion provides much clarity. The fact that Time Machine cannot backup an evicted file, is not an unexpected consequence of this technology. I presume there is still some link record that points to the iCloud that would allow you download the file during a restore. But it would appear you lose all the history/versioning of the an evicted file. Or do you effectively wind up with incremental snapshots in iCloud? I don’t recall seeing this explained or documented.

Design-wise, I would prefer that a file marked for eviction would not actually be deleted on the Mac, until the space was actually needed.

Jerry

LikeLiked by 1 person
36

Fernando on March 12, 2024 at 6:14 pm
Reply

Thanks for helping us all understand what happens when we start flipping the iCloud toggles in Sonoma. I’m glad to know neither I nor my computer were going crazy when my Optimize Mac Storage setting kept toggling itself back to its initial state!

LikeLiked by 1 person
- 37
  
  hoakley on March 12, 2024 at 9:18 pm
  Reply
  
  Thank you. That’s so consistent I wonder if it’s deliberate.
  Howard.
  
  LikeLike