I have been wanting to buy the MBA M1 for so long. My plan is to just go ahead and buy it, then run DriveDx t o see how much is written and read. If the amount is reasonable, good. If not, return. This plan sounds ok?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
M1 Mac Users Report Excessive SSD Wear
- Thread starter MacRumors
- Start date
- Sort by reaction score
From https://appleinsider.com/articles/2...m1-mac-ssd-longevity-based-on-incomplete-data
As said before: Those values are probably wrong. Interpretation of SMART values is a lottery, even more in this case, as Apple uses proprietary tech.
I got my base m1 air on launch day. I use it everyday just for general usage but on weekdays likely a few hours and on weekends more like 8 hours (cycle count on battery is 49 if that tells anything). I am at 1.7TB so far so I am not seeing the issue
I don't confuse anything. Unless you show me the Apple spec where it says that the base model is not good enough for most users you are the one who doesn't seem to understand the meaning of Pro.
What I really hope is, that this will get enough attention that Apple decides to make "official" way to monitor storages health.
Similarly what they did with iphone battery health. And since macs are "compicated computers", maybe a bit more in detail.
There are some mysteries unfold:
https://appleinsider.com/articles/2...m1-mac-ssd-longevity-based-on-incomplete-data :
"For example, published results of the tool repeatedly show users as having relatively low counts of "Power On Hours," typically in the low-hundreds and lower. For Macs running for two months, this seems to be a little low compared to what would be expected."
Similarly what they did with iphone battery health. And since macs are "compicated computers", maybe a bit more in detail.
There are some mysteries unfold:
https://appleinsider.com/articles/2...m1-mac-ssd-longevity-based-on-incomplete-data :
"For example, published results of the tool repeatedly show users as having relatively low counts of "Power On Hours," typically in the low-hundreds and lower. For Macs running for two months, this seems to be a little low compared to what would be expected."
Since I installed Big Sur 11.2.2 this morning my swap hasn't been above 64MB (M1 Mac Mini 16GB/512). They must have added something in the update:
This an excellent example of "stupid journalism".
In general, people have been writing articles and posts with their fantasies and interpretations for a week now instead of studying the official NVMe specification and finally figuring out what the "Power On Hours" parameter of NVMe SSD means and measures. Or at least to ask for a quote from real experts.
NVMe specification is not a secret at all. This specification could be easily found on the main page of the official website of NVM Express (https://nvmexpress.org/).
On pages 122 and 123 anyone can find a detailed explanation of "Power On Hours", "Data Units Written", "Percentage Used" etc.
"Power On Hours" in NVMe SSDs measure only the real working time of SSD, time that it spent in I/O operations, etc, and not include standby time.
Both smartmontools and DriveDx are following the specification of the NVMe standard.
Weird thought, and maybe this came up already, I only had time to read the last ~5 pages of this thread. Could Google Chrome be the culprit?
My M1 Mini doesn't seem to have these wear problems. However, I noticed it DID have really use resource usage until I uninstalled Chrome (yes, including the initial ARM version).
What percentage of you that are experiencing these high-levels of wear have Chrome installed? And before anyone asks, I understand that Activity Monitor, etc say "Chrome" isn't taxing your system but it is documented (Chrome is Bad) that even installed Chrome increases system level activity mostly due to how Google handles it's constant, background updates.
I'm not trying to pass around tin foil hats, this is just a thought after skimming through the problem. There doesn't seem to a common thread between the people experiencing the issue other than web usage.
My M1 Mini doesn't seem to have these wear problems. However, I noticed it DID have really use resource usage until I uninstalled Chrome (yes, including the initial ARM version).
What percentage of you that are experiencing these high-levels of wear have Chrome installed? And before anyone asks, I understand that Activity Monitor, etc say "Chrome" isn't taxing your system but it is documented (Chrome is Bad) that even installed Chrome increases system level activity mostly due to how Google handles it's constant, background updates.
I'm not trying to pass around tin foil hats, this is just a thought after skimming through the problem. There doesn't seem to a common thread between the people experiencing the issue other than web usage.
Thanks for the reference to the spec. It looks like NVMe is more specific on the SMART Health information log pages than previously in the SATA specs. Now I’m completely convinced that the SMART info for at least the M1 NVMe SSDs is accurate. The spec posted above is not ambiguous in any way.
Here's one data point. Chrome hasn't ever been on my M1, and I am seeing zero unexpected TBW.
This issue has already been figured out.
This "issue" is caused by incompetent people that were using software that was not calibrated for use with the SSD hardware Apple uses in its computers.
Where have you been?
Not true. @killerovsky posted the NVMe spec here https://forums.macrumors.com/threads/m1-mac-users-report-excessive-ssd-wear.2285892/post-29640500
The smartmontools code is using the same offsets into the SMART health info log page as what is defined in the spec.
If you write a specific amount of data to your SSD and use smartctl to monitor the TBW you will see that it matches exactly. I’ve done that experiment here
Edit: I had to wrong link to my post. Sorry for any confusion. Link is here: https://forums.macrumors.com/thread...n.2284893/page-13?post=29639724#post-29639724
Last edited:
Nice deflection attempt but a lot of people like myself use Chrome because Safari is broken and writes is normal in the ~500GB.
It is now noted that you have no idea what a base specification is, nor does killerovsky.
I also note that absent all evidence to the contrary, neither of you works for Apple or any manufacturing partner of Apple. We know this to be true as merely discussing this in public would be a violation of an Apple NDA and your jobs would be instantly forfeit should Apple Security discover it.
That being said, we can also deduce you do not know how to read. To wit, I quote :
"If you are not a Member of NVM Express, Inc. and you have obtained a copy of this document, you only have a right to review this document or make reference to or cite this document. Any such references or citations to this document must acknowledge NVM Express, Inc. copyright ownership of this document. The proper copyright citation or reference is as follows: “© 2007 to 2019 NVM Express, Inc. ALL RIGHTS RESERVED.” When making any such citations or references to this document you are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend the referenced portion of this document in any way without the prior express written permission of NVM Express, Inc."
Since neither of you posted such a declaration, you are both in violation of copyright law and provably did not read a word of the source you cited.
Insert mic drop here.
Assuming facts not in evidence.
Nobody, let alone you or killerovsky, has established Apple is using the literal, verbatim base specification as the sole implemented specification used to control their SSDs, especially in light of the fact they are using a custom chip for the controller.
Once again I point out even if you could prove it, Apple would come down on you and killerovsky like a ton of proverbial bricks for violating your respective NDAs. The simple reality is neither of you any earthly idea what is going on. However, I am relying on history which has shown time and again "issues" like this are started by people filled with teh dumb. I doubt history will prove me wrong this time.
Sorry that you can’t accept the evidence. It isn’t complicated. You write a certain amount of data and that amount of data is reflected in the output of the tool. It isn’t remotely possible that this is incorrect but you believe what you like. I’m not sure what your rant about NDAs is about but ¯\_(ツ)_/¯
The post I linked uses simple arithmetic to show that writing to the M1 SSD is perfectly represented in the output of smartmontools smartctl. There can be no possibility that anything is estimating inputs and outputs wrong unless you think that the Finder and Apple's Activity Monitor are also not accurate. If you can't explain what you mean about estimating inputs and outputs in the context of the data, then I'm not sure if there is anything more to be said.
Wear levelling on SSDs in the past few years is pretty good (which is only needed on writes, reads don't impact wear) - and at least with some manufacturers/controllers will use the "spare blocks" as part of the wear levelling (Apple has not detailed this for their implementation that I've seen, but I would suspect they would do the same). The more full the drive is, the harder it is to wear level, so there still can be some cells that will fail before others, as well as possibility of defects. As some real-world tests have found - most SSDs will last well beyond the advertised endurance (Measured in TBW). So a drive reporting 0% drive life remaining (having "consumed" it's 400, 600, whatever TBW), could still operate fine for years after that. Having worked with over a couple hundred of SSDs from multiple companies for years, only a handful have failed (Pretty much all of the 10 Samsung 840 Pro - but none of the 850 or 860 Pros that replaced them, a couple SanDisk low-end 120 GB out of likely 100 or so, and one Crucial MX300 out of another 100 or so, one 2014 MacBook Air SSD after just over 2 years out of around 50 Macs with SSDs from Apple)
As expected your response doesn't address the fact that when you write data to a SSD, actual bytes are written to the drive. You can measure that byte count and compare it to the TBW from the SMART monitor. How SSDs write is complicated but the wear is from both erasing blocks of data before writing and then the actual writing of the pages. If your SSD is new or you get lucky, it doesn't have to erase the block before writing since a free page is available but over time eventually the SSD has to do garbage collection on the old blocks to reuse them for newer writes. So the wear leveling in the drive gets complicated but as a general measure, TBW averages that all out over time. It is a decent measure of wear on the drive which is why it is called out in the SMART Health log pages.
As expected you posted absolute gibberish which doesn't have anything to do with anything.
Please delete your account.
To everyone else : Given that Apple has now issued a statement backing up that which I have posted - that being the software used to generate this 'issue' got the numbers wrong - please delete your accounts as well if you disagree with me.
So you admit that you can't answer the question of how the Finder and the TBW number from smartctl match if the numbers are wrong.
https://www.extremetech.com/extreme/210492-extremetech-explains-how-do-ssds-work
Since you still have precisely zero clue as to how SSD *reporting* works, especially in light of Apple stating the numbers used to create this "issue" are wrong, do everyone a huge favor and delete your account.
So you admit that you can't answer the question of how the Finder and the TBW number from smartctl match if the numbers are wrong.
You're saving it wrong! It's obviously a feature to remind you to replace your computer after a reasonable amount of time.