Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I'll also quote from a story published on this by a rival site, which cites an anonymous source within Apple.

"While we're looking into the reports, know that the SMART data being reported to the third-party utility is incorrect, as it pertains to wear on our SSDs" said a **** source within Apple corporate not authorized to speak on behalf of the company. The source refused to elaborate any further on the matter when pressed for specifics.
 
The software uses official MacOS IOKit APIs to retrieve the SMART data. If there is some “magic” involved it is a bug in MacOS. Not impossible but unlikely since all available data from multiple sources on the same computer are in agreement. You can correlate the writes of the SSD between the Finder, Activity Monitor, and smartctl (third party smartmontools) very easily.
Well... its undoubtedly a bug in macOS. The question is... where?
 
  • Like
Reactions: Phantom iCloud tabs
Well... its undoubtedly a bug in macOS. The question is... where?
I've been thinking about this rationally as I'm waiting to receive my order for an MBA M1 16GB/2TB after seriously considering to cancel it. It's not logic for an SSD to be writing all by itself without receiving instructions to do so. Clearly it's software that sends those writing instructions, so it has to be something that can be fixed with an update. The question is, is it a bug in macOS (whatever the version), in one of Apple's native apps or in a third-party app?
 
I've been thinking about this rationally as I'm waiting to receive my order for an MBA M1 16GB/2TB after seriously considering to cancel it. It's not logic for an SSD to be writing all by itself without receiving instructions to do so. Clearly it's software that sends those writing instructions, so it has to be something that can be fixed with an update. The question is, is it a bug in macOS (whatever the version), in one of Apple's native apps or in a third-party app?
I just opened up every application on my M1 16GB/1TB MacBook Air, at least 60 applications. I had 20 tabs open in Safari. I ran two copies of centOS in Docker, one Arm64 the other x86_64. I tried everything to get my MBA to swap and finally got it to use a bit more than 2 GB of swap. It didn't budge the TBW number after an hour.

Basically, like a lot of bugs, this one is triggered by some condition that we currently aren't clear on. It certainly doesn't happen to every M1 Mac. I wouldn't worry about it too much especially with a 16GB/2TB Mac. The 2 TB will have a larger TBW and getting a 16 GB M1 Mac to swap is difficult (at least it seems to be hard to do on my MBA.) When you get the MBA, just monitor it occasionally. The more people analyzing this, the faster we will figure out what triggers it (unless Apple gets there first and gives us a clue.)
 
Okay!
I originally planned to use 2TB hdd with those parts of my homedir that doesn't need speed (Movies, Music, Pictures) with mini2018. Then I learned that Apple doesn't "support" this.

This hdd is always on and plugged to my mini.
It has 16996 hours in SMART.
(Seagate FireCuda 2.5 ST2000LX001-1RG174)

And Total_LBAs_Written is 8707455762.
Which then translates to 8707455762 * 512000 / 10^12= 4458 Tbytes written? Maybe not...
The 512,000 Byte per unit consensus is among NVMe SSD makers.

In your SATA hard drive reading, the column already tells you it is based on a different math. "Total_LBAs_Written" where LBA is "logical block addressing"; I think a typical disk is 512 Bytes per sector unless you have a special 4096 (4K) disk (which is almost exclusively used on SSDs)

My rough math ended up with your reading translating into 4.05 TB. Sounds right for a 17000 hour old 2TB everyday drive.
 
Considering Apple has been using soldered SSD since at least 2017 I find it interesting the only now are people worrying about the RAM and SSD being soldered on the logic board: "Bottom line is you can't upgrade the SSD or anything on that model as RAM and storage are both soldered onto the logic board."
I find the timing natural. 4-5 years after soldered ssd's became standard to every new mac, or at least huge majority, people are buying used macs that have ssd's which lifespan can be quite near to the end. And usually neither seller or buyer can't even find out the lifespan of the ssd.
Replaceable SSD are just as much apart of that "throwawayism" as what Apple is doing. Heck every replaceable part has much the same throwawayism" issue because what one do with the old part? Why throw it away. :eek: :D
There's economical, technical and enviromental side to this. If components are soldered and thus non-replaceable, when one component is damaged or too old, slow or small, you'll have change everything, not just the part that causes the need to change.
And when we are dealing with Apple, those mb's are very expensive.
And when those are out of stock, you can't even replace that.
If you have older mac, you don't need that mb to be still sold. You can change the ram and ssd and the mac is suddenly years younger in terms of performance.

Apple can change the current style if they want. Or there can be regulation that forces Apple to do it.
 
My rough math ended up with your reading translating into 4.05 TB. Sounds right for a 17000 hour old 2TB everyday drive.
Too much for this. This is not a system disk.
Even I have a version of macos installed also in this disk, I only use it for those: Music, Movies, Pictures.
And then ther's Shared, which holds my "permanent" Download section, all manuals for harware and sw archive and bunch of other documentation.

Only thing that might do some digging there is Photo's building that strange monument of hers.
But can it possibly mean writing over a terabyte per year?
Or does Spotlight repeat its job very often?
 
Latest News from the ongoing issue of the of SSD,s on the M1 Mac
just wasted 5 minutes before I shut it off ... nothing a moderately tech savvy MAC user doesn't already know. I have ActivityMonitor open all the time on my new mba m1 and fairly closely watched it in the last two weeks, and the swap is not the problem, but I do notice that kernel_tast, launchd and other components of OS writes far frequent and more to SSD even I barely do anything on the computer. For example, SafariBookmarksSyncAgent wrote 2.38G in 9days of up time. In contrast, SafariBookmarksSyncAgent wrotes only 546Mb on my 2015 MBA in 128 days of up time!

There are constant writing activities even the computer is completely idle, something I don't see on other macs. Now I am pretty convinced that this problem has something to do with M1/Big Sur, and the excessive writing is real for every M1 user, although most of us probably will not have a dead SSD before moving on to a new computer.
 
Last edited:
just wasted 5 minutes before I shut it off ... nothing a moderately tech savvy MAC user doesn't already know.
Two things here.

1) No truly tech savvy Mac user uses "MAC" for the computer as that abbreviation actually stands for Media Access Control a unique identifier assigned to a network interface controller which is used in Windows and Linux machines. So I can honestly say that everyone on the internet uses MAC even if only 10% (at best) use Macs. :p

2) The video past the 5 minute mark is where it gets more informative. The 6:30 mark is where they show the way three of their M1 have behaved via smart tools.

Is There A Problem? Swap Memory on M1 Macs took similar data and blind box figured what the TBW for the SSDs Apple uses:

Base formula: TB/TBWx100 = percentage.
TB = percentage/100 * TBW
TB/(percentage/100) = TBW
TB*100/percentage = TBW

So if 3.5% has been used for 5.32 then the TBW is 152 which giving the rounding is 150. However the Apple M1 SSDs video actually show 0% which causes this equation to fail. If we move it up to 1% so the equation works we get 5.32/(1*100) = 530 TBW.

Is There A Problem? actually came up with an a TBW of ~1500...on a 256 GB SSD!
 
Last edited:
With this problem with the M1 Mac, do you regret buying the M1 Mac?
And wished you had waited to see how things panned out?
 
With this problem with the M1 Mac, do you regret buying the M1 Mac?
And wished you had waited to see how things panned out?
Most M1 Mac owners aren't seeing any problem. I've had my M1 MacBook Air since the first day they were available (Nov. 17, 2020) and I have a perfectly normal amount of TBW at 7.25 TB. I use the M1 MBA at least 10 hours a day. So to answer your question, no regrets here.

Edit: For reference, that would be about 240 TBW over 10 years.
 
Is There A Problem? actually came up with an a TBW of ~1500...on a 256 GB SSD!
That is the main "smoking gun" here.
There's no 256GB ssd with TBW of 1500.
Or is there?
Apple's own secret ssd?
Everybody can check from teardowns what chip they used and what are the "normal" TBW for those...

Is this "life percentage" maybe same kind than in iphone's battery?
Like when it has dropped 20% (to 80%), the phone is pretty much unusable.
Apple could have scaled it so that today's 80% would be 0% and therefore the number would drop 5 times faster.
Which would make user worried. "So, lets make a percentage that is not percentage."
Since they have done it before, why not now?
 
That is the main "smoking gun" here.
There's no 256GB ssd with TBW of 1500.
Or is there?
Apple's own secret ssd?
Everybody can check from teardowns what chip they used and what are the "normal" TBW for those...

Is this "life percentage" maybe same kind than in iphone's battery?
Like when it has dropped 20% (to 80%), the phone is pretty much unusable.
Apple could have scaled it so that today's 80% would be 0% and therefore the number would drop 5 times faster.
Which would make user worried. "So, lets make a percentage that is not percentage."
Since they have done it before, why not now?
Remember this "life percentage" is not from Apple's tools but someone else's. ie smartmontools and DriveDx.

If as you say the numbers are projecting TBW that are totally off the wall gonzo insane then either the TB*100/percentage = TBW formula is wrong or the numbers themselves are garbage.

This formula is the inverse of the one everyone is using to calculate the life of the drive ie TB/TBWx100 = percentage. So 3.7 TB that is 2% then at 185 TBW the drive would be at 100%. 3.7*100/2 is indeed 185 which proves the formula is correct.

Since the formula is show to be valid per "eliminate the impossible than what remains not matter how improbable is the truth" something is causing these non Apple tools to produce nonsense data.
 
Last edited:
This is pretty intriguing.
If Apple says that the numbers are wrong, then they had to show the right numbers.
Which probably won't happen before the court rules so.

There's also no obligation for Apple to follow NVMe specs for SMART data.

For the user there's only win.
Even Apple opens the real numbers or they get sued by class action when those drives start popping after few years.
Plenty of time to pop your corn before the fun begins.
Hopefully EU has banned soldered ssd from "computers" by then...
 
Remember this "life percentage" is not from Apple's tools but someone else's. ie smartmontools and DriveDx.

If as you say the numbers are projecting TBW that are totally off the wall gonzo insane then either the TB*100/percentage = TBW formula is wrong or the numbers themselves are garbage.

This formula is the inverse of the one everyone is using to calculate the life of the drive ie TB/TBWx100 = percentage. So 3.7 TB that is 2% then at 185 TBW the drive would be at 100%. 3.7*100/2 is indeed 185 which proves the formula is correct.

Since the formula is show to be valid per "eliminate the impossible than what remains not matter how improbable is the truth" something is causing these non Apple tools to produce nonsense data.
The tool just reads what is stored on the drive. So the data is either coming from the SSD controller on the M1 or macOS. Either way it is on Apple to supply the correct data.
 
The tool just reads what is stored on the drive. So the data is either coming from the SSD controller on the M1 or macOS. Either way it is on Apple to supply the correct data.
No one has successfully explained how this can possibly be due to some bogus calculations when people have measured the actual data being read/written at the same time as the drive monitoring tools (that use said calculations) and they are both accurate/correct.
 
  • Like
Reactions: jdb8167
No one has successfully explained how this can possibly be due to some bogus calculations when people have measured the actual data being read/written at the same time as the drive monitoring tools (that use said calculations) and they are both accurate/correct.
According to a quote from an (admittedly anonymous) Apple engineer that I reproduced in my last comment in this thread, the numbers are not accurate. If that is correct--and I suspect that even an anonymous Apple employee would not mislead in a case like this, where the truth will eventually come out--then it will be just a matter of time before additional evidence bears this out. Right now, in spite of the endless but understandable speculation by M1 users and potential M1 buyers, this thread is almost entirely populated by hyperbole.
 
  • Disagree
Reactions: jdb8167
According to a quote from an (admittedly anonymous) Apple engineer that I reproduced in my last comment in this thread, the numbers are not accurate. If that is correct--and I suspect that even an anonymous Apple employee would not mislead in a case like this, where the truth will eventually come out--then it will be just a matter of time before additional evidence bears this out. Right now, in spite of the endless but understandable speculation by M1 users and potential M1 buyers, this thread is almost entirely populated by hyperbole.
As pointed either here or in another thread a representative from Apple told our Apple User group back in the day that the reason Copland was taking so long that there was a lot of black box code in the old OS.

That guy wasn't anonymous and I am still not sure how true what he claimed was. From everything that has come out it looks like feature creep was more to to blame then what amounted to 'we don't know our own code' (though that is a possiblity given the patchwork quilt code was back then)

But the fact that back checking via TB*100/percentage = TBW formula seems show these tools are spouting nonsense which supports the claim
 
Last edited:
According to a quote from an (admittedly anonymous) Apple engineer that I reproduced in my last comment in this thread, the numbers are not accurate. If that is correct--and I suspect that even an anonymous Apple employee would not mislead in a case like this, where the truth will eventually come out--then it will be just a matter of time before additional evidence bears this out. Right now, in spite of the endless but understandable speculation by M1 users and potential M1 buyers, this thread is almost entirely populated by hyperbole.
The statement by the “corporate source” never made much sense and given the refusal to elaborate, I would give it no credence. Even if it came from an Apple flak it doesn’t mean they know what they are talking about. And the complete silence following it says to me that it is bogus. The data is coming from the SSD which implies the controller which is custom on the M1 SoC. Why did Apple not design the controller to report accurately?
 
The statement by the “corporate source” never made much sense and given the refusal to elaborate, I would give it no credence. Even if it came from an Apple flak it doesn’t mean they know what they are talking about. And the complete silence following it says to me that it is bogus. The data is coming from the SSD which implies the controller which is custom on the M1 SoC. Why did Apple not design the controller to report accurately?
While I agree that the “corporate source” even if legitimate may have had no clue about what they were talking about there is the whole unified memory thing which throws a whole new dynamic into the equation.
 
While I agree that the “corporate source” even if legitimate may have had no clue about what they were talking about there is the whole unified memory thing which throws a whole new dynamic into the equation.
C'mon, it's not like the source was a Senior Advisor :)
 
While I agree that the “corporate source” even if legitimate may have had no clue about what they were talking about there is the whole unified memory thing which throws a whole new dynamic into the equation.
Why would that matter?
 
Why would that matter?
It takes more memory to move higher resolutions around. It takes less memory to push 1280 x 720 around then it does for 1920 x 1080. (Just based the dimensions you are talking 2.25 more RAM for the higher resolution)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.