MacInTouch Amazon link...
Channels
Apple, Products
Has anyone discovered anything new about this issue or tried the "Clean My Drive" workaround? I prefer not to use 3rd-party software when I can avoid it. This is a real annoyance for me as I back up a few computers and transfer Logic X files back and forth almost daily with a USB 3 stick and I'm sometimes waiting 30-90 seconds for Apple to be done with the drive before I can eject it. If I'm booted into Snow Leopard 10.6.8, any type of external drive ejects instantaneously. This issue seems to have nothing to do with:
- Spotlight​
- How it's ejected (i.e. Finder window, right-click, drag to Trash)​
Any current thoughts, solutions, or workarounds for this silly problem? Anyone know what changed in the Mac OS since Snow Leopard that causes this?
Take a look at this website to explain why the delay in ejecting a drive. Scroll down to "Why would you need to eject a drive?"
 


Has anyone discovered anything new about this issue or tried the "Clean My Drive" workaround? I prefer not to use 3rd-party software when I can avoid it. This is a real annoyance for me as I back up a few computers and transfer Logic X files back and forth almost daily with a USB 3 stick and I'm sometimes waiting 30-90 seconds for Apple to be done with the drive before I can eject it. If I'm booted into Snow Leopard 10.6.8, any type of external drive ejects instantaneously. This issue seems to have nothing to do with:
- Spotlight​
- How it's ejected (i.e. Finder window, right-click, drag to Trash)​
Any current thoughts, solutions, or workarounds for this silly problem? Anyone know what changed in the Mac OS since Snow Leopard that causes this?
Use Sloth or the lsof terminal command to list open files on the volume that you're trying to eject.

What I've found is that when a drive doesn't want to eject, it is because some application decided to run from it instead of from the startup drive. The chief offender is the 1Password agent.
 


Do you have any antivirus/antimalware software running? I've found that if I cancel a scan of a USB drive, it ejects much more quickly. Otherwise, it waits for the scan to complete before ejecting, probably because the system sees that the volume is "in-use."
Excellent thought, but I do not have any 3rd-party antivirus/anti-malware running in the background and never have.
 


Take a look at this website to explain why the delay in ejecting a drive. Scroll down to "Why would you need to eject a drive?"
Interesting. If this article from 2015 is correct, then it looks like I can't fix this:
Do You Really Need to Eject Your Flash Drive (or Device) Before Removing It?
... The reason is because operating systems use a process called write caching. The operating system doesn’t always write a file to a drive immediately, but instead caches it and waits until it has multiple write operations to complete.

Doing these all at once improves performance, but if the cache is still full when you remove the drive, your data will become corrupted. Clicking the Eject button causes the cache to be emptied and any remaining data to be written to the drive.

That’s the reason why there’s often a delay of several seconds between ejecting the drive and being notified that it’s safe to remove it.
Thanks for the post! I wish there was a way to tell the drive to write the files immediately vs. having the files cached first. I wonder if there is a Terminal command for this or a GUI app?
 


Interesting. If this article from 2015 is correct, then it looks like I can't fix this:
Thanks for the post! I wish there was a way to tell the drive to write the files immediately vs. having the files cached first. I wonder if there is a Terminal command for this or a GUI app?
The amount of time you have to wait for the cache to be flushed is measured in fractions of a second. The point of the article is: don't just yank a USB thumb drive out of the port, eject first. The eject should happen right away; if it doesn't then that means that there are still files actually open on the drive. That is, you're waiting for an application to release the file, not waiting for the cache.

Also, for what it is worth, Microsoft is changing the policy in Windows 10 so that it no longer caches writes to USB drives (thus decreasing performance for all flash drives :-(
 


Ric Ford

MacInTouch
The amount of time you have to wait for the cache to be flushed is measured in fractions of a second.
How did you reach that conclusion? macOS does very extensive caching*, and there can easily be > 8 GB of RAM available for cache use. (Writing 8+ GB to diisk icertainly won’t happen in “fractions of a second.”)

*For example:
 


Also, for what it is worth, Microsoft is changing the policy in Windows 10 so that it no longer caches writes to USB drives! (Thus decreasing performance for all flash drives. :-(
It is worth pointing out that Microsoft is changing the default policy in Windows 10. The same article you linked explains how to change the setting back if desired. Inconvenient? Definitely. But not impossible.

When Apple decides to make those kinds of changes, they're rarely that nice about it.
 


How did you reach that conclusion? macOS does very extensive caching*, and there can easily be > 8 GB of RAM available. (Writing 8+ GB to diisk icertainly won’t happen in “fractions of a second.”)

*For example:
I think I read it in discussions of file system caching & integrity*, and specifically how does the file system really know when a write is successful. One of the points was that the caching between when an application does a write and that write is written to disk is only moments.

The caching for reading can be a long time, but that's not the question here. It is how long are you at risk for disk corruption due to an interrupted write.

If I'm wrong here I look forward to being corrected!

* Probably it was a discussion of whether the OS can assume that if the drive controller says the file is written, is it safe to assume it really is? Or, perhaps it was a argument over whether the safeguards in ZFS are actually necessary.
 


Ric Ford

MacInTouch
For what it's worth, I just looked at Activity Monitor on a fairly idle Mac running macOS Sierra, and it shows 2.64 GB for "Cached Files".

Now, I don't know if those are cached for writing or just cached for reading - i.e. I don't know if they'd have to be written to disk prior to dismount/shutdown - but that's a lot of data!

A quick trip to Capture One, and Cached Files jumps to 3.45 GB, while Memory Used also jumps up (to 10.53 GB out of 16 GB Physical Memory).

Open Postbox and a Finder folder, and Cached Files goes to 4.35 GB.

(Swap Used is still at 0 bytes - cool. :-)
 


I have a half-dozen external hard drives (all connected via USB 3), and the wait time for unmounting to actually take place was a minute or more (and sometimes some drives would refuse to unmount at all).

A portion of the time (15 seconds?) was the drives spinning up; the rest was, if I recall correctly, Spotlight being quite insistent upon finishing whatever the h*ll it thought was necessary.

I put all the drives into Spotlight's Privacy pane, and the largest portion of the delay disappeared. But no more quick searching available. I'm using Commander One for searching now. (Ironic that I'd have to use a clone of Norton Commander in Mojave, eh?)
 


... and the wait time for unmounting to actually take place was a minute or more (and sometimes some drives would refuse to unmount at all). A portion of the time (15 seconds?) ...
I put all the drives into Spotlight's Privacy pane, and the largest portion of the delay disappeared.
My external spinning hard drives are already spun up, and ejection time is about 45 seconds, so we agree on the time span.

Adding all my drives to the Spotlight Privacy pane has sadly done nothing for me for spinning drives or for USB flash drives.
 


MacInTouch home page said:
LaunchControl is a Mac utility from Soma-zone that lets you control what programs are running on your Mac by provding a graphical interface to the operating system's critical "launchd" mechanism. Features include a control palette that shows all manner of "jobs" (running programs), including background, hidden and startup programs (e.g. Google's updater; Apple's gamed and photoanalysisd; firewall programs, disk drivers, backup programs and much, much more), providing details about status, invocation, options and program locations, plus numerous controls over their operation (along with built-in help and tooltips).
(Note that changes to Apple processes, such as disabling unwanted Apple Game Center or photo-analysis daemons, require turning off "SIP" via the csrutil disable command, which must be entered from Recovery mode on the Terminal command line.)
So, has anyone played around with this? Will it remember which programs to kill when you reboot? I wonder if this could help with the slow eject drive issue? Is there a caching program I could kill?
 



As I've mentioned before in the context of shared network volumes, Path Finder allows immediate ejection of mounted volumes. Perhaps they are not subject to content caching?
 


Ric Ford

MacInTouch
As I've mentioned before in the context of shared network volumes, Path Finder allows immediate ejection of mounted volumes. Perhaps they are not subject to content caching?
That's an interesting observation. I used to have problems with long delays for drive ejection and/or shutdown but haven't seen the problem lately, despite working with backup drives containing millions of files. But I also use Path Finder (Version 7).

I do see some delay for drive ejection, by the way, but it's probably less than 10 seconds.
 


Ric Ford

MacInTouch
So, has anyone played around with this? Will it remember which programs to kill when you reboot? I wonder if this could help with the slow eject drive issue? Is there a caching program I could kill?
Yes, LaunchControl works across reboot, and I am currently experimenting with disabling gamed and photoanalysisd — no problems found so far.

I would be very reluctant, though, to mess with caching mechanisms.

Instead, I'd suggest using Sloth (and maybe Activity Manager) to see what files are open on your drive that may be delaying its dismount.
 


Just a quickie: If you are using Retrospect, Instant Scan can stop unmounting. Edit the retro_isa.ini text file (in ~/Library/Application Support/Retrospect Folder) to weed out any volumes you would rather not get scanned all the time.

Or just stop it in the System Preferences/Retrospect preference pane: Disable Instant Scan. I only scan my boot drive and external user space; all other drives (including intermittent drives) are asked nicely to [go away], and they do.
 


Ric Ford

MacInTouch
This is a real annoyance for me as I back up a few computers and transfer Logic X files back and forth almost daily with a USB 3 stick and I'm sometimes waiting 30-90 seconds for Apple to be done with the drive before I can eject it. If I'm booted into Snow Leopard 10.6.8, any type of external drive ejects instantaneously.
Use Sloth or the lsof terminal command to list open files on the volume that you're trying to eject.
I just had a thought about identifying the files that might be slowing down drive dismount.
  1. Get Find Any File (if you don't already have it).
  2. Get to the point where you normally eject the drive and see a delay.
  3. Note the exact time on your computer.
  4. Wait, doing nothing for, say, two minutes.
  5. Eject the drive (presumably waiting for the delay time).
  6. Note the exact time on your computer.
  7. Re-attach the drive.
  8. Open Find Any File.
  9. Search for Modification Date is within the past, say, 8 minutes (hold down the Option key when clicking Find to Find All) for the drive in question.
  10. Sort the results by time and look to see what changed between the first time you noted and the second time you noted. These should be the problematic files.
Personally, though, I would be very reluctant to use USB sticks for heavy data work, as I would expect them to have errors that may not be apparent. Instead, I'd use a real SSD (e.g. Samsung T5) or hard drive, which at least have built-in error correction and SMART data reporting.

Also, flash "thumb" drives are incredibly slow, even vs. hard drives, so if you're worred about delays, they're obviously a poor option.
 


That's an interesting observation. I used to have problems with long delays for drive ejection and/or shutdown but haven't seen the problem lately, despite working with backup drives containing millions of files. But I also use Path Finder (Version 7). I do see some delay for drive ejection, by the way, but it's probably less than 10 seconds.
I don't have time at the moment to play around with Path Finder (after visiting the site, I don't see anything it offers that I really need or want), but this is interesting. If what you and Christopher say is true, what is it in Path Finder that allows for faster ejections? Does anyone here communicate with the software author? If so, can you ask why it's faster? If we find out, maybe there's a Terminal command that can be used to make this adjustment for faster ejections with the standard Apple Finder.
 


Ric Ford

MacInTouch
... what is it in Path Finder that allows for faster ejections? ... If we find out, maybe there's a Terminal command that can be used to make this adjustment for faster ejections with the standard Apple Finder.
I searched the Objective Development website for info on caching and checked Path Finder 7 preferences but didn't find anything. It may simply be Finder dysfunction, which wouldn't surprise me at all, but, as I noted earlier, the big picture is that using cheap USB sticks (or SD cards, for that matter) is not the way to achieve either quick data transfers or reliability.

I do see a similar thread on Macrumors:

And I have had some mounting (but not dismounting) issues with USB sticks myself lately (running macOS Sierra), but I never figured out exactly what was causing them — hardware issues, conflicts (e.g. between SMART SAT driver and SoftRAID or a serial driver) or what.

Are you using a USB MIDI interface, camera controller or anything like that?

You could also try some cache cleaning/optimization, e.g. with Onyx or Northern Softworks' Cache Cleaner. Even just erasing the flash drive completely might help if you really want to stay on that path, but file-sharing or a simple NAS or AirPort shared drive might be easier/better if you don’t want to use a decent portable SSD.
 


Are you using a USB MIDI interface, camera controller or anything like that?
No, I am not. But I may have failed to mention that I have the exact same issue with FireWire 800 spinning drives connected to an OWC drive-dock toaster when I am backing up with Carbon Copy Cloner.
You could also try some cache cleaning/optimization, e.g. with Onyx or Northern Softworks' Cache Cleaner.
That makes sense, I'll give that a try later or in the next day or two.
Even just erasing the flash drive completely might help if you really want to stay on that path, but file-sharing or a simple NAS or AirPort drive might be easier/better if you don’t want to use a decent portable SSD.
Good point. On this particular USB 3 64GB Samsung stick, it has a mini version of macOS 10.12.6 that I was using a while back for a dosdude1 install and just left on there. I have noticed that there is less of a delay in general with drives that do not contain an OS (data only), but the delay is still there. Also, as I mentioned before, all and any type of drives/media eject immediately with Mac OS X 10.6.8 Snow Leopard. Something changed.
 


I just had a thought about identifying the files that might be slowing down drive dismount.
  1. Get Find Any File (if you don't already have it).
  2. Get to the point where you normally eject the drive and see a delay.
  3. Note the exact time on your computer.
  4. Wait, doing nothing for, say, two minutes.
  5. Eject the drive (presumably waiting for the delay time).
  6. Note the exact time on your computer.
  7. Re-attach the drive.
  8. Open Find Any File.
  9. Search for Modification Date is within the past, say, 8 minutes (hold down the Option key when clicking Find to Find All) for the drive in question.
  10. Sort the results by time and look to see what changed between the first time you noted and the second time you noted. These should be the problematic files.
I don't have "Find Any File", but I can download and try it later this week. As I also said in a recent post, it does seem faster to eject any type of drive if it doesn't have an OS on it. But, there is still a delay with media-only drives (compared to Mac OS X 10.6.8).
Personally, though, I would be very reluctant to use USB sticks for heavy data work, as I would expect them to have errors that may not be apparent. Instead, I'd use a real SSD (e.g. Samsung T5) or hard drive, which at least have built-in error correction and SMART data reporting.
I have OWC drive dock toasters in both rooms where the two computers are, but it's more of a pain in the buttocks to use them for what is literally a couple of files each time, and I get the same delays with Finder drive ejection via FireWire 800 and spinning drives. This is something to do with Sierra and other recent OSes.
 


I do see a similar thread on Macrumors:
The poster said,
Just checked that the problem doesn't happen with Snow Leopard. It ejects instantly there. The slow eject/unmount is with ElCapitan. Was anything changed in ElCapitan which would cause pendrives to take more than a minute to eject?
Yes, I did have this issue with El Capitan also. I skipped all the OSes between Snow Leopard and El Capitan, so I don't know if this problem started before or with El Cap. And again, this is all types of drives for me, not just USB pendrives.
 


Ric Ford

MacInTouch
Also, as I mentioned before, all and any type of drives/media eject immediately with Mac OS X 10.6.8 Snow Leopard. Something changed.
Well, yes, there was quite a big change that occurred with OS X 10.9, which drastically slowed hard drives. It was so bad, I had to upgrade computers for a variety of users from hard drives to SSDs to recover adequate performance. That was years ago.

As I understand it, Apple not only failed to optimize OS X 10.9 (and later) for hard drives, it actively de-optimized them. It's very low-level, geeky, poorly documented stuff, but I think we've posted/linked some additional details on MacInTouch in the past.

I hadn't thought about whether or not this issue affected USB "pen" drives, but perhaps it did. In any case, an SSD should be much faster with OS X 10.9 and later vs. hard drives (and possibly "pen" drives).
 


A possible source of slowness in thumb drives is whether they use a native Windows format (such as ExFAT) or are initialized as a macOS volume (e.g. HFS+). My experience has been that they're a lot slower if they haven't been reinitialized as a macOS volume, though that isn't much help if your application is copying/backing up between other OSes and macOS.
 


As I understand it, Apple not only failed to optimize OS X 10.9 (and later) for hard drives, it actively de-optimized them. It's very low-level, geeky, poorly documented stuff, but I think we've posted/linked some additional details on MacInTouch in the past.
I would be surprised if anyone sat down and decided "let's see what we can do to make hard drives slower." I'm sure it was more along the lines of "this new feature that we really want is going to have the side effect of hurting hard drive performance, but that's OK because we're trying to phase out hard drives anyway".

We know, for example, that APFS's copy-on-write semantics (especially in conjunction with snapshots and multiple file revisions) result in massive amounts of file fragmentation, completely trashing hard drive performance.

In other words, slower hard drive performance being a side-effect of a design decision, not the reason for that decision. Without a smoking gun document, I wouldn't want to make any assumption about motivation.

Of course, for you and me, motivation doesn't matter - the effect is the same.
 


The "drive eject delay" problem has existed for me since at least OS X 10.8 Mountain Lion (I didn't run 10.7). I've experienced it to varying degrees on OS X 10.8 and macOS 10.12 Sierra. USB thumb drives, FireWire and USB spinners all have suffered with this problem.

The latest macOS 10.12.6 with all updates has minimized it, I'm unsure whether any of the updates was the cure. It was quite a problem for a while, on OS X 10.8 and macOS 10.12, me waiting (no so) patiently for a drive to eject, sometimes for a minute or so.

I never moved through OS X 10.7, 10.9, 10.10, and 10.11, nor will I move beyond macOS 10.12 until I'm forced to for security.

I'm hoping macOS 10.14 Mojave might prove stable for a couple of years? (Don't want to wait until 10.18 — Mac OS X 10.6.8 was most stable, macOS 10.12.6 stable... notice the pattern? Will there even be a macOS 10.18?)
 


Drive dismount delay has been annoying me for years, but due to illness I haven't had the energy/time to try to figure out the what and why – or even when it started being a problem, though I know there was a time when it was not. So I've just been putting up with it, though getting increasingly tired of that and numerous other "little" glitches in macOS. If anybody wants to investigate, a utility named What's Keeping Me might be helpful.
 


Well, yes, there was quite a big change that occurred with OS X 10.9, which drastically slowed hard drives. It was so bad, I had to upgrade computers for a variety of users from hard drives to SSDs to recover adequate performance. That was years ago.
This was why I stayed so long on Mac OS X 10.6.8. I had tested other OSes on partitiions and wasn't impressed. I had to wait until I was flush enough to replace all my internal drives with SSDs before moving to El Capitan, OS X 10.11.
 


A possible source of slowness in thumb drives is whether they use a native Windows format (such as ExFAT) or are initialized as a macOS volume (e.g. HFS+). My experience has been that they're a lot slower if they haven't been reinitialized as a macOS volume, though that isn't much help if your application is copying/backing up between other OSes and macOS.
Interesting thought Joe, but I'm thinking the opposite. I always erase every new drive and format it as "Mac OS Extended (Journaled)" if I'm even possibly planning on putting an OS on there. (If it's definitely only for media, I typically just leave it alone).

When I get a chance later, maybe I will see if not formating with Mac OS Extended (Journaled) makes a difference when using a drive only for media and transfer. I'd like to see if the "MS-DOS (FAT)" drives have the same ejection delay problem.
 


Ric Ford

MacInTouch
I would be surprised if anyone sat down and decided "let's see what we can do to make hard drives slower." I'm sure it was more along the lines of "this new feature that we really want is going to have the side effect of hurting hard drive performance, but that's OK because we're trying to phase out hard drives anyway".
I recall it reading about the issue and feeling that it seemed like a perverse and unnecessary design decision in its impact on hard drives, not one justified by trade-offs for SSD improvements, but I just searched extensively and couldn't find the reference. I know it wasn't an Apple document, and I just dug around John Siracusa reviews, MacPerformance Guide, Amit Singh material, MacInTouch, and more without hitting it, unfortunately. It might be in some video presentation, e.g. at MacSysadmin or something, but I didn't find it in a quick perusal of some videos.

My takeaway was an operating system change that actually hurt hard drive performance, [but I'm not sure it was coincident] with OS X 10.9 [which apparently had other (different) changes that slammed performance with hard drives] even as it was doing optimizations (memory compression) to help mitigate hard drives slowdowns.

It was related to something like blocksizes, caches, memory management, compression — along that line, and nothing that was getting headline stories at all, just geeky low-level details.
We know, for example, that APFS's copy-on-write semantics (especially in conjunction with snapshots and multiple file revisions) result in massive amounts of file fragmentation, completely trashing hard drive performance.
Yes, and I've got loads of documentation on that issue, but what I was trying to turn up was an earlier hard drive performance issue that preceded APFS.

Apple may have mitigated some of the issue I'm referring to in more recent years — I'm not sure, as I completely abandoned hard drives for system boot and most other uses.

High Sierra APFS had issues with Fusion drives that seem to have been addressed in Mojave, and I guess you can even run Mojave on a hard drive, but I haven't wanted to do that experiment, personally.
Of course, for you and me, motivation doesn't matter - the effect is the same.
Actually, it only really matters to me as an issue of technical curiousity and detail. I'm not about to go back to using hard drives or recommending them to anyone else for anything but archives and backup (or very high capacity). I even found Linux and Windows pokey enough on hard drives that I set those up on SSDs, as well. (I really care about responsive performance. :-)
 




Ric Ford

MacInTouch
I would be surprised if anyone sat down and decided "let's see what we can do to make hard drives slower." I'm sure it was more along the lines of "this new feature that we really want is going to have the side effect of hurting hard drive performance, but that's OK because we're trying to phase out hard drives anyway".
I recall it reading about the issue and feeling that it seemed like a perverse and unnecessary design decision in its impact on hard drives, not one justified by trade-offs for SSD improvements, but I just searched extensively and couldn't find the reference.
Simon found the reference (bless him!):
I've been doing more digging, and this is what I've found so far:
comp.sys.mac.system said:
Why Mavericks is slow or fast or needs an SSD
10.9 : The broken VM tuning from 10.7 is fixed and augmented with compression. VM compression consumes some RAM of its own but it generally outperforms 10.6 virtual memory. Apple also adds a fix for processes that monopolize the filesystem: Each process is throttled. ... Again, a new fix backfires horribly. Processes that shouldn't be throttled and don't need to be throttled still get throttled. In my case, applications were getting just 300KB/sec of filesystem throughput; a 97% loss compared to 10.8 and worse again compared to 10.6.

People who install an SSD notice a vast improvement while people who already have an SSD notice that it still seems slow. ... Apple has provided a less aggressive throttle if an SSD is being used, which is why an SSD helps in cases where spinning rust should suffice.
 


Thanks for the link. It sheds a bit more light on the issue.

It seems there have been problems for a very long time (going back at least to Mac OS X 10.6) with processes hogging too much CPU time, hogging too much memory, hogging too much file system I/O, etc., resulting in seemingly hung systems (resulting in the Spinning Pizza of Death mouse pointer). There were many attempts to fix this, all failing for different reasons, the last of which because hard drive performance got clobbered.

The article concludes that this is because HFS+ needs to be replaced and everything else is a stopgap/hack. It would appear that Apple concurred, ultimately resulting in the release of APFS (which also has performance problems on hard drives, but for a completely different set of reasons).
 


Very interesting: I found OS X 10.9 pretty sluggish, compared to Snow Leopard, but stuck with it for a long time because of an application I wanted to keep using.

I also attributed some of the sluggishness to my main boot drives having been upgraded so many times. (One drive in my Mac Pro had a system cloned from Tiger.) However, when I finally upgraded my main boot drive from Mavericks to Sierra, I was surprised to discover that performance was greatly improved.

This Mac Pro contains only hard drives, no SSDs. I don’t remember much about OS X 10.8, since I barely used it, but every other OS—10.10, 10.11, 10.12, and, of course, Mac OS X 10.6—has run significantly better than 10.9, enough better that I haven’t bothered to install any SSDs.
 


Interesting thought Joe, but I'm thinking the opposite. I always erase every new drive and format it as "Mac OS Extended (Journaled)" if I'm even possibly planning on putting an OS on there. (If it's definitely only for media, I typically just leave it alone).

When I get a chance later, maybe I will see if not formating with Mac OS Extended (Journaled) makes a difference when using a drive only for media and transfer. I'd like to see if the "MS-DOS (FAT)" drives have the same ejection delay problem.
In my experience, ejecting USB thumb drives that are formatted as MS-DOS (FAT) is usually quick. Drives that I've reformatted with HFS+ to use as bootable installers are slow ejecting, usually because Spotlight is trying to index the drive's contents, something it can't do for FAT drives. Dragging the drive to Spotlight's privacy list will stop the indexing and allow a quick ejection, but you have to do it for each drive on each Mac you use them with.
 


In my experience, ejecting USB thumb drives that are formatted as MS-DOS (FAT) is usually quick. Drives that I've reformatted with HFS+ to use as bootable installers are slow ejecting, usually because Spotlight is trying to index the drive's contents, something it can't do for FAT drives. Dragging the drive to Spotlight's privacy list will stop the indexing and allow a quick ejection, but you have to do it for each drive on each Mac you use them with.
I've only used HFS+ thumb drives as installer disks. [See How to create a bootable installer for macOS. —Ric Ford]

When using them as data drives, I never experienced a slow dismount, perhaps because I tended to have a small number of very large files, which would have been easy for mdworker to index quickly.

This was a few (maybe four?) years back, but we did a survey of drive speeds, durability, and prices, and ended up purchasing several of these drives:

A few years before, when we were building OS X (then as) installer media, we ended up purchasing Patriot Rage drives. Since I no longer see their thumb drives showing up in "best of" lists, I don't know whether their performance is lagging others now, or there's some other reason.
 


In my experience, ejecting USB thumb drives that are formatted as MS-DOS (FAT) is usually quick. Drives that I've reformatted with HFS+ to use as bootable installers are slow ejecting, usually because Spotlight is trying to index the drive's contents, something it can't do for FAT drives. Dragging the drive to Spotlight's privacy list will stop the indexing and allow a quick ejection, but you have to do it for each drive on each Mac you use them with.
True but I thought that if you eject any drive while it is being indexed, Spotlight will just cease indexing. Maybe the delay is while it updates the index on the drive for the data found so far?
 


I guess you can even run Mojave on a hard drive, but I haven't wanted to do that experiment, personally.
We bought three new 2014 Mac Minis last year, solely for the purpose of having a sure way to keep Quicken 2007 going into the (sadly) indefinite future. These are the most basic Minis sold, dual-core i5, 4GB RAM, 500GB hard disk drives. I set the first two up with USB 3.0-connected SSD clones of our standardized Sierra installs, from which I removed as much of Apple's bloatware valuable included software as possible.

Last week, I unboxed the third Mini, which shipped with Sierra. I updated it to Mojave, just to see how Quicken 2007 works on that last and final version which will support 32-bit. I have so far been pleasantly surprised by the performance of that extremely low-end Mac, on Mojave, on a 5400-RPM hard disk drive. Then, the only thing that's being run on it is Quicken 2007 (and those Apple daemons the company kindly provides). There are no photos to grind the CPU, as Apple runs face and object identification, and no iCloud connection or automatic updating. I've not dug into what I can shut down and/or even remove from Mojave, but I turned off all those notifications about stocks, news, etc.

One thing I hadn't anticipated, since "Dark Mode" seemed nothing special, because I've been using it on Linux for several years: Apple's "Dark Mode" really improves my experience, which had been decaying with light, narrow fonts on blinding white backgrounds.
Very interesting: I found OS X 10.9 pretty sluggish, compared to Snow Leopard
Had three old original Intel iMacs that were orphaned on Snow Leopard. The two 20" models had 250GB HDDs, don't remember what the third 17" hard disk drive was. Don't know if they were all 5400 RPM or might have been 7200. Snow Leopard all the way through 10.6.8 ran great on them.
 


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

Latest posts