Will HFS+ Damage SSDs?

[Alvin777]

Hello Mac friends,

Will using HFS+ damage SSDs (understanding that APFS was made of SSDs and HFS+ is for hardisks, for mechanical drives)? This is for Time Machine (speed is not a priority). If HFS+ won't damage the SSD, I'm switching from APFS to HFS+ hoping I won't get the 'not enough space' again even though both my Time Machine and macOS SSDs have the same capacity of 1TB (it may be a macOS bug- not sure).

Thank you in advance.

 

[Bigwaff]

Time Machine in Sonoma requires APFS. You’ll be prompted to reformat if the disk isn’t already formatted APFS. The only way to use HFS+ with TM is if you have an existing HFS+ disk with an existing TM back up on it.

 

[casperes1996]

HFS+ does not damage SSDs. It works just fine. However, as Bigwaff says, there are other limitations at play for using HFS+ these days. It's a legacy filesystem at this point.

As for not enough space, TimeMachine makes incremental backups all the time. It makes sense for it to take up *more space* than the machine you back up as it tries to keep several versions of everything as far back as it can.

 

[Fishrrman]

I continue to use HFS+ on ALL my drives (HDDs and SSDs), UNLESS the drive is REQUIRED to be in APFS (such as an internal boot drive).

HFS+ drives are still "reach-able" using 3rd party drive utilities.

APFS drives are not (no 3rd party utilities seem to be able to "touch them", as Apple has kept some of the specs proprietary).

 

[casperes1996]

I continue to use HFS+ on ALL my drives (HDDs and SSDs), UNLESS the drive is REQUIRED to be in APFS (such as an internal boot drive).

HFS+ drives are still "reach-able" using 3rd party drive utilities.

APFS drives are not (no 3rd party utilities seem to be able to "touch them", as Apple has kept some of the specs proprietary).

I mean, just a very quick search, reveals as hit 1 on Google, that Paragon does have an APFS product for 'touching' APFS from Windows

APFS for Windows | Paragon Software

Read and write APFS-formatted HDD, SSD or flash drive on Windows computer.

www.paragon-software.com

There's also plenty of open source Mac software that interacts with APFS

 

[Fishrrman]

casperes wrote:
"There's also plenty of open source Mac software that interacts with APF"

Can you name one or two that can repair or defrag APFS volumes?

 

[Bigwaff]

Can you name one or two that can repair or defrag APFS volumes?

SSD don’t need to be defrag (and should not be) … and now it’s down to “repair”, and you make good point. There aren’t any other than Apple’s CLI tools (which Disk Utility calls under the hood). Any GUI app purporting to “repair” APFS volumes, whether it be commercial or free, is probably doing the same… delegating to Apple’s tools under its hood.

 

[casperes1996]

casperes wrote:
"There's also plenty of open source Mac software that interacts with APF"

Can you name one or two that can repair or defrag APFS volumes?

A Bigwaff says, defragging SSDs is not recommended. Diskutil does allow you to enable defragmentation of APFS, but I'm not sure if it actually performs it on SSDs or only HDDs.

As for repair, I can't speak to rebuilding volume maps and such, but if you just want files off of a corrupted APFS disk there are third party utilities, not relying on diskutil. Take a look at this article wherein one of these tools is used to mount an APFS Volume the system doesn't recognise

APFS Object Map Recovery (free)

More data recovery options for APFS:

GitHub - jivanpal/drat: Utility for performing data recovery and analysis of APFS partitions/containers.

Utility for performing data recovery and analysis of APFS partitions/containers. - jivanpal/drat

github.com

https://github.com/cugu/afro // Outdated

Or the Linux tools

GitHub - linux-apfs/linux-apfs-rw: APFS module for linux, with experimental write support

APFS module for linux, with experimental write support - linux-apfs/linux-apfs-rw

github.com

 

[Fishrrman]

casperes

The "tools" you list in reply 8 above are pretty much "beyond the reach" of an average user.

Let me know when we see apps like "TechTool", "Drive Genius", etc., come online that can perform the same operations with APFS as they do with HFS+.

Also, it's STILL possible to use drive utilities on HFS+ drives, running under the latest OS's (assuming they'll still run).

Example:
I can run an older version of "iDefrag" on my MacBook Pro 14" using Sonoma -- "aimed" at HFS+ drives (not SSDs).
Still works.

 

[casperes1996]

casperes

The "tools" you list in reply 8 above are pretty much "beyond the reach" of an average user.

Let me know when we see apps like "TechTool", "Drive Genius", etc., come online that can perform the same operations with APFS as they do with HFS+.

Also, it's STILL possible to use drive utilities on HFS+ drives, running under the latest OS's (assuming they'll still run).

Example:
I can run an older version of "iDefrag" on my MacBook Pro 14" using Sonoma -- "aimed" at HFS+ drives (not SSDs).
Still works.

Sorry I may have misunderstood the issue at hand. I thought the discussion was “is it at all possible for expert users to manipulate apfs drives”. Not whether there are streamlined, user friendly utilities for it.

In that case I question what an average user needs outside of Fisk utility but I’m sure there are use cases. And of course hfs+ still works and you can use a manipulate the drives like before. But there are limitations. Like installing macOS directly to the drive

 

[Minghold]

Will using HFS+ damage SSDs (understanding that APFS was made of SSDs and HFS+ is for hardisks, for mechanical drives)?

No. And that last bit is mostly propaganda. I.e., you'll note that Windows 11 retains the HFS+ equivalent NTFS file-system despite most PCs coming with SSDs. While APFS does have a few desirable features, such as volumes sharing empty space on a drive, it's really all about "security" and data-compartmentalization, with Apple selling those as features (but with the ulterior motive of knowing that the users who forget their passwords will be stuck with a brick rather than being able to at least wipe the drive and start over). In my experience, APFS runs considerably slower that HFS+ on any drive and in any OS where either is an option. In particular, never run APFS on a rotational-drive; Apple seems to have deliberately designed that filesystem to run like dogshat in order to artificially-obsolesce its own intel-era machines by making the APFS-mandatory Catalina an OS update path for rotational-drive iMacs and Minis from 2012 to 2019 (turning them into utter slugs while also deprecating the user's pile of old, paid-for 32bit-version software).

This is for Time Machine (speed is not a priority). If HFS+ won't damage the SSD, I'm switching from APFS to HFS+ hoping I won't get the 'not enough space' again even though both my Time Machine and macOS SSDs have the same capacity of 1TB (it may be a macOS bug- not sure).

Do this: 1) Get a large-capacity external drive (I'm partial to the 5TB shirt-pocket drives). 2) Using disk utility, erase it to MacOS Extended journaled (most drives come with the ExFAT file system), then create its first partion to be the same size as your internal drive's boot-partition (so, usually 500gb or 1TB). 3) Use Carbon Copy Cloner 5 to auto-sync backup the internal drive to that external partition on a daily basis (and this partition will also be bootable. 4) If you want to use TimeMachine too, direct it into a different partition you'll create on the external (and set the size of that partition to be as big or small as you deem appropriate to your situation, as TimeMachine treats empty hard-drive space the way Ebola treats Africa).

Lastly, I recommend EaseUS Data Recovery Wizard for corrupted file-structure data-loss or emptied-trash deleted-file situations (open that link only in JDownloader2, or in a browser with the uBlock Origin extension installed).

 

[HDFan]

Get a large-capacity external drive

Yes. Get a drive at least 3x the size of the drive to be backed up with TM.

then create its first partion

I would not partition the drive as you then can't easily move it off site in the recommended 3-2-1 backup strategy. If the drive fails and you have TM and CCC backups on the same drive you lose both backups.

Only one of the recommended 3-2-1 backups should be TM due to its tendency to fail. All 3 backups should be on different drives.

 

[Minghold]

Yes. Get a drive at least 3x the size of the drive to be backed up with TM.

That is, IMO, needlessly extravagant for TM, especially since....

Only one of the recommended 3-2-1 backups should be TM due to its tendency to fail.

...as you note, it sucks.

I would not partition the drive as you then cannot easily move it off site in the recommended 3-2-1 backup strategy. If the drive fails and you have TM and CCC backups on the same drive you lose both backups.

I view the 5tb 2.5" external as primary external storage with a portion devoted to a synced bootable clone backup. For 3-2-1 offsite drives, additional CCC partition clones (of the internal drive, and documents in spill-over storage on the 5tb) are IMO vastly superior to TM. (My first impression of TM, when it was introduced all those years ago, was that it was an incredibly cockamamy and obtuse rip-off of the concept (if not form in practice) of CCC, and expressly designed to eventually swallow up all available drive space.

 

[BigTimEnergy]

If it puts your mind at ease you could maybe buy a cheap 128GB SSD and see how long it takes to brick it, I bet most people couldn’t manage it in their lifetime with normal home use..

 

[HDFan]

That is, IMO, needlessly extravagant for TM, especially since....

The larger the size the longer the retained history. The minimum recommended size evidently is 2x. When at 3x I had almost a year of history. Now that I am at 2x (more data being backed up) history is down to 6 months or less.

 

[bzgnyc2]

If it puts your mind at ease you could maybe buy a cheap 128GB SSD and see how long it takes to brick it, I bet most people couldn’t manage it in their lifetime with normal home use..

"normal home use" is the key. Agree for people doing basic browsing office/productivity work they should be fine for the life of the device (i.e. at least 10 years).

However, what I've found helpful (and a lot easier than my own durability testing) is to calculate my average "GB/day" and then estimate when I'll reach the TBW for the drive. For my laptop where I do basic productivity work, that is typically 3-6GB/day. Assuming 6GB/day and the 128GB SSD with 300 writes (the low-end), that would still get me over 15 years.

Then on systems where I move more data, I have runs of 1TB+/day. There I'm glad my now aging 1 TB SSD is rated at 1200 TBW. A drive a 300 TBW might have died by now.

At the other extreme, suppose you're continuously capturing data at 1 GB/sec (often +/- many SSD's max sustained write rate) to a 1 TB drive, processing before moving to another system, and then overwriting. Even a 1200 TBW drive might only last 2 weeks under those circumstances. An array of larger SSD might last long enough, but a medium-sized RAID (i.e. 5-12 drives) of HDD likely a better design.

Somewhat more common, suppose some sort of continuous video recording (e.g. security cameras) at 100MB/sec. There a 1 TB drive with a 1200 TBW (above average for that size) might die in less than 6 months (est. avg 140 days at spec). Depending, a single HDD or an array of larger SSD likely a better design.

However, people in the last two categories should know they are in those categories. They just need to know to engineer a solution for their situation. Most people should assume they are in the first category.

To estimate one's "GB/day", just get total GB written since your last reboot and the total time since the last reboot (this should be reliable enough after the computer has been on a few days assuming you don't reboot multiple times per day). Easiest way to get Data Written is to go to Activity Monitor->Disk and check "Data written". To get the time of last reboot, go to System Information->Diagnostics->Last Run (or easier if you use Terminal, just run "uptime") and just calculate the number of hours since then and divide by 24. Then the average "GB/day" is just the ratio.

 

[ignatius345]

Only one of the recommended 3-2-1 backups should be TM due to its tendency to fail.

Is that true of the APFS, snapshot-based version of Time Machine, though? The old version on HFS+ was a mess because the whole thing was a rat's nest of symlinks. I've found the new version quite a lot more robust.

 

[Minghold]

The larger the size the longer the retained history. The minimum recommended size evidently is 2x. When at 3x I had almost a year of history. Now that I am at 2x (more data being backed up) history is down to 6 months or less.

Probably 95% of a TM archive is bloat: multiple, multiple, multiple copies of the same stuff gobbling an entire drive. (This is a major reason that I avoid Apple's ecosystem apps: E.g., I don't put my picture and music into iTunes and Photos libraries, which are then trusted to TM. --I put them into ordinary folders on the main-drive level (i.e., outside of the user folder), then let CCC handle the archiving.

The old version on HFS+ was a mess because the whole thing was a rat's nest of symlinks. I've found the new version quite a lot more robust.

HFS+ at least had some 3rd-party utilities that could sort it out (e.g., Apple should have bought out DriveDr, as it was obvious they were capable of doing what Apple's disk-utility tweakers were not); with APFS you are flat screwed if it goes pearshaped, and in the best of circumstances will be spending the rest of the day Command-R reinstalling the OS from scratch and then sweating bullets that your TM archives are there to import from uncorrupted.

 

[Fishrrman]

Ming munged things up with:
"Probably 95% of a TM archive is bloat: multiple, multiple, multiple copies of the same stuff gobbling an entire drive. (This is a major reason that I avoid Apple's ecosystem apps: E.g., I don't put my picture and music into iTunes and Photos libraries, which are then trusted to TM. --I put them into ordinary folders on the main-drive level (i.e., outside of the user folder), then let CCC handle the archiving."

Couldn't have said it better, so repeating for emphasis.

My advice to any Mac user would be to AVOID APFS (and time machine, too), except in those use cases where one MUST use APFS (such as newer Mac boot drives, and backups. I believe even CCC and SuperDuper will require APFS for backing up newer OS's these days).

The internal SSD on my 2018 Mini (with a t2 chip) has four "hard" partitions:
Boot - APFS
Main - HFS+
Media - HFS+
Music - HFS+

This way, I have APFS only where required, and I was able to coax disk utility into making "the rest of it" HFS+, as well...

 

[Minghold]

Ming munged things up with:
"Probably 95% of a TM archive is bloat: multiple, multiple, multiple copies of the same stuff gobbling an entire drive. (This is a major reason that I avoid Apple's ecosystem apps: E.g., I don't put my picture and music into iTunes and Photos libraries, which are then trusted to TM. --I put them into ordinary folders on the main-drive level (i.e., outside of the user folder), then let CCC handle the archiving."
Couldn't have said it better, so repeating for emphasis....

It's going to happen any day now (i.e., almost a certainty within the next two years): somebody will finally solve the Linux Problem, and, once solved*, an easily-duplicatable and bootloader'd solution will spread exponentially to take over the planet as everyone adopts. Microsoft, Apple, and all the accredited business-partner hardware OEMs (with their brave-new-world dreams of today's-"secure"=tomorrow's-bricked computers being planned-obsolescence third major purchases after homes and cars) will be left holding their dicks wondering what happened. (*It's already partially solved on the PC side, as you can run most Windows apps in Linux with Wine or similar open-source utility.)

 

[HDFan]

Is that true of the APFS, snapshot-based version of Time Machine, though?

APFS is certainly better for TM than HPFS. TM for all file system types involves a lot of pointers. As such it is more vulnerable to failures than a simple file system, even if they are rare. Haven't had any of my 5 TM backups fail recently, but the two simultaneous failures I had a long time ago are seared into my memory.

Probably 95% of a TM archive is bloat: multiple, multiple, multiple copies of the same stuff gobbling an entire drive.

Can you explain? TM is designed to not have "multiple copies of the same stuff".

 

[Minghold]

APFS is certainly better for TM than HPFS. TM for all file system types involves a lot of pointers. As such it is more vulnerable to failures than a simple file system, even if they are rare.

This is a reason for replacing TM with CCC-created bootable backup syncs, not replacing HFS+ with APFS (e.g., such as in the ubiquitous bad-advice to upgrade a 2012-2019 era Mac's comfortable-old-shoe OS to Catalina+).

 

[Sciuriware]

APFS is certainly better for TM than HPFS. TM for all file system types involves a lot of pointers. As such it is more vulnerable to failures than a simple file system, even if they are rare. Haven't had any of my 5 TM backups fail recently, but the two simultaneous failures I had a long time ago are seared into my memory.



Can you explain? TM is designed to not have "multiple copies of the same stuff".

As TM is designed to run almost constantly it will 'swallow' lots of copies of files that have minor meaning,
but change constantly, sometimes by a few bytes (e.g. caches).
TM was set up to serve organisations like software houses, where they constantly work on many sources.
For 'ordinary' people such is useless: those need at most one backup per day or one extra after huge changes.
Although I'm a (retired) programmer, I can live with one backup every 3 weeks, with some local copies
of crucial files. Those who take lots of pictures need only one backup after they have unloaded their camera.
But don't let me stop you from useful saving your files.
;JOOP!

 

[HDFan]

As TM is designed to run almost constantly it will 'swallow' lots of copies of files that have minor meaning,
but change constantly, sometimes by a few bytes (e.g. caches).

True. But:

1. You can configure TM to ignore caches
2. Doesn't really affect disk space that much. With a TM 2x larger than the source disk I can almost maintain a year's worth of TM backups.

TM was set up to serve organisations like software houses, where they constantly work on many sources.

None of the software companies that I have worked for over the years used TM. Can you provide a source for this statement?

 

[Sciuriware]

True. But:

1. You can configure TM to ignore caches
2. Doesn't really affect disk space that much. With a TM 2x larger than the source disk I can almost maintain a year's worth of TM backups.



None of the software companies that I have worked for over the years used TM. Can you provide a source for this statement?

I'm retired since 2006, so I do not have actual info. Moreover, several of companies I worked with have disappeared.
Maybe they used TM too much? (LOL)
;JOOP!