None beyond what's already been discussed in the Adobe forum. And school is still out if that is an Adobe problem, or Apple problem, or both. Until you run an M1 version, the suspicion remains on Adobe.
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.
ssd swap - high usage of Terabytes Written
- Thread starter Forti
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
But, it's a LOT faster with 100 tabs than my 5 y/o mini. People with other Apps might have to wait for M1-specific ports. Games don't seem to be an issue.
Can I ask what the heck some of you are doing with your computers that you have this much disk activity?
Here is my activity monitor currently on my M1 mini.
Here is my activity monitor currently on my M1 mini.
I rebooted earlier tonight, that was probably 6 hours ago. I don't have many tabs open, 4 right now counting this one, and I don't use Lightroom.
edit: Right now iStat Menus says I am using zero swap.
edit: Right now iStat Menus says I am using zero swap.
@leons, you seem to be knowledgeable in this and I can see you have been very helpful, so appreciate your work.
My question is, could you summarize a list of things that I need to keep an eye on?
For example:
1. In the AM, I know I should go to the "Disk" tab and look at the "data written" down the bottom.
2. Download driveDX and see the SSD health indicator percentage and "data written".
But what else? I only know those two. What else should I keep an eye on?
My question is, could you summarize a list of things that I need to keep an eye on?
For example:
1. In the AM, I know I should go to the "Disk" tab and look at the "data written" down the bottom.
2. Download driveDX and see the SSD health indicator percentage and "data written".
But what else? I only know those two. What else should I keep an eye on?
The other common one is Smartmontools run via Terminal.
You need to physically disconnect (not just unmount) any external drives before reading the Activity Monitor number, and divide it by the time since boot (from System Info > Software) to get your current GB/h.
EDIT see Units are the same so it is a Units to TB factor, bits vs bytes I guess.
Last edited:
Differnent calc to convert 512 byte sectors written e.g. 31,547,052. Smartctl is calculating it as data units*512/1000/1000/1000. DriveDx is calculating it differently but is reporting basically the same data blocks read/written which is what the TB figure is derived from
Thanks! So it is a sector size issue, rather than bits vs bytes as I said above? The difference isn't significant but interested in which is deemed more correct.
The most current workarounds for LR are in this thread - https://feedback.photoshop.com/conv...-with-rosetta/5fd7cefe7288d52d004c5a1c?page=2
Be aware that, as keeps being repeated in the above thread, this is clearly more than just a Rosetta issue, since LR CC, which is Silicon native, still has these issues.
In terms of the debate about whether Apple would ‘do the right thing’ if this ever were a provable point of failure after warranty, etc., this is recent news -
www.macrumors.com
My personal concern about this issue ever being covered under any kind of warranty/recall would be how to prove it was a design/software flaw and not just excessive usage by the end user?
Not everyone has the issue and we don’t in fact know how widespread it is, as only a tiny percentage of users delve into this kind of thing. Add this to the fact that no issue is being admitted, and I’m not so sure - due to SOC, we’re not talking about Apple sucking up replacement of a few SSDs here, but essentially replacing entire machines.
I dunno, but let’s say I’d do everything not to have to test that particular avenue. Which currently means using your expensive computer not as you wish to, but in a way to work around an issue. Not how it should be, IMO of course.
Apple Knowingly Sold 2016-17 MacBook Pro Models With 'Flexgate' Display Defect, Judge Says
In 2019, some customers of 2016 and 2017 MacBook Pro models began to notice an odd "stage lighting" effect that would impact their screen,...
www.macrumors.com
My personal concern about this issue ever being covered under any kind of warranty/recall would be how to prove it was a design/software flaw and not just excessive usage by the end user?
Not everyone has the issue and we don’t in fact know how widespread it is, as only a tiny percentage of users delve into this kind of thing. Add this to the fact that no issue is being admitted, and I’m not so sure - due to SOC, we’re not talking about Apple sucking up replacement of a few SSDs here, but essentially replacing entire machines.
I dunno, but let’s say I’d do everything not to have to test that particular avenue. Which currently means using your expensive computer not as you wish to, but in a way to work around an issue. Not how it should be, IMO of course.
The problem is Smartmontools is clearly producing nonsense and Smart isn't the "standard" everyone thinks it is.
16.1 TB x 100/0.49999 (the worst it can get before showing 1%) gets us a TBW of 3,220. That is totally nuts and way too high.
"Unfortunately, regardless of the storage technology, there is no industry-wide standard to tell you which numbered SMART attribute describes a specific physical property of a drive The attribute descriptors will vary between SSD and HDD, and even between the various SSD vendors.
There are several third-party utilities that can retrieve and report a drive’s SMART data, often available in freeware and shareware. However, unless the third-party software vendor consults with the drive vendor on correct SMART attributes, their definitions and thresholds (when applicable) are likely to mislabel the attributes and can lead to false-positive or false-negative failure reports. (...) Incorrectly reported or misinterpreted SMART data can lead to incorrect conclusions which, can, unfortunately, lead to the return of a perfectly functional drive."
Also someone posted an Activity Monitor that showed mds_stores (part of Spotlight) having written 415.75 GB but Data Written showing only 178.15 GB written or 42.850% and there were other processes that had written data. The numbers just don't make sense as I don't think there is any kind of compression going on before the data is actually written to the SSD.
I think this has been debated earlier in the thread, from which my understanding is that the actual numbers for data written to disk are valid, and that the questionable part is the criteria for life usage and interpretation. Depending on how this pans out the whole topic may be a non- issue. Is that how you see it?
The post you mentioned with the Activity Monitor screen was mine in this post. It does look wrong, but at that stage I hadn't realised that Activity Monitor includes external drives, and the numbers change if you physically disconnect the externals. I use externals a lot and don't know how that screen would have changed if I had disconnected them. The total in the bottom right shows only the data for the drives connected at that point. I don't know if the same is true for the process data like mds. Since those processes are still running, the data may not be recorded on a disk by disk basis. My current Activity Monitor screen after 4h28m, with no externals, does not have that anomaly. I am going to pay more attention in future.
Someone else has pointed out that 16.1 TB (Terabytes) is close to 14.7 TiB (Tebibytes) so maybe DriveDx should be reporting 14.7 TiB.
TB to TiB conversion
The high swap usage does occur on the M1 non-Rosetta version of Lightroom CC as well. Including Luminar AI (which is not Adobe).
It's definitely an Apple problem given that it occurs with so many apps.
Not a totally non issue as there are clearly programs that are way too write happy (Chrome for various reasons)
The problem with the previous Activity Monitor results is that Data written is supposed to show all data written to all drives. mds_stores (part of Spotlight) wrote 415.75 GB somewhere and given how Data Written is supposed to work it should have shown at least 415.75 GB but it only showed 178.15 GB written or 42.850% of what it should have showed minimum.
Yes with everything unconnected the numbers make sense but, and this the kicker, one of the external was causing Activity Monitor to go off its nut and produce nonsensical data.
It's like having an internal wattage meter for your house that says one device uses 200 W/H but your external wattage meter shows only 90 W/H - it makes no flipping sense. Sure unplugging the device makes the numbers make sense...still doesn't explain why the numbers were in la la land when it was plugged in.
Not convinced about that. The YouTube vid was clearly only talking about the disk write number in the lower right window (that was 178.15GB in my post). I didn't watch the whole 25 minutes but he didn't say anything about what the AM numbers against the individual processes represented. In the period before I took that screenshot I had had 7 TB of external disks connected so it wouldn't be unreasonable for Spotlight to have done a lot of writing, and without knowing more about the inner workings of AM it isn't possible to say what that 415.75GB means, and how it behaves on disconnect of the externals. I would not find it surprising in a line about the process kept the total written by that process.
The Youtube vid is quite clear that using the number in the bottom right is a valid quick and dirty way of seeing the data written to all disks. He discussed the effect of having a TM backup disk connected and how that would contribute to the total, but he didn't seem to realise that the number will change to internal only if the backup disk is disconnected, as I showed in this post, confirming what someone had reported earlier.
So far, focussing on the bottom right number, as in the YouTube video, with not externals attached, does seem be a valid method of assessing the short term rate of SSD writes.
EDIT I have just connected 12 TB of externals to my M1 MBA and will see if I can reproduce the situation where the spotlight process shows a large number, and what happens to it when the 12TB of externals are disconnected. I deleted the spotlight indices on them to force it to rebuild them.
Last edited:
Please stop reposting outdated articles if you are not familiar with the topic. This article was about old (S)ATA S.M.A.R.T. In this thread, we discuss NVMe SSDs. This is a completely different standard. It has a clear open specification and a whole set of fully standardized attributes such as Data Units Written, Percentage Used, etc. I have already published a link to the NVMe standard several times in this thread, on page 123 - you will find a full description of all the parameters you are interested in.
Now about why data in Activity Monitor may sometimes not sync with SMART Data Units Written:
1) ActivityMonitor aggregates data written to all connected drives
2) Activity Monitor and drive firmware have different data polling times: Activity Monitor is almost real-time, drive firmware update polling time can be 1 minute or more (dependent on firmware).
Bingo! Exactly, you are right.
Thanks. That difference shouldn't matter in the context of high TBW, where hours and days are more relevant than minutes.
My Activity Monitor screenshot (shown again below) from my earlier post does have an apparent inconsistency which I asked about and Maximara is pointing out, that the sum of the numbers in the data written column clearly exceeds the total Data Written number in the bottom right corner. I am inclined to regard this as something we don't understand about Activity Monitor reporting than indicating AM is meaningless for the TBW issue.
I am pretty sure the anomaly occurred because, shortly before that screenshot I had had 12 TB of prime data and backup drives connected for some time time. This would have caused the big mds process number. While they were connected the Total written number would have been much larger than 178, from all the backup data movement. When the screenshot was taken the drives had been disconnected, so the total written came right down, but I think the mds did not. The tests I mentioned above to reproduce this will confirm (or otherwise!).
The problem with "indicating AM is meaningless for the TBW issue" is that people have been using what AM says to confirm that smartmontools' "Data Units Written" isn't producing nonsense. More over it was a report by smartmontools that triggered off this whole thing.
The above shows that something is messing with AM and since those who have bothered to crosscheck smartmontools is producing data have said it is within a sane margin of error we have basically no tool with with to check that is going on with the SSD. Wonderful. Might as well be arguing how many angels can dance on the head of a pin.
Statements with words like "meaningless" and endlessly repeated dated quotes won't help here. If all the data is meaningless, then let's all do nothing and just pray. I and several others here with solid technical backgrounds have made the determination that the issue can be mitigated in most cases to a level that assures the SSD will most likely outlive the machine, regardless of any reasonable assumptions of the margin of error in any of the numbers reported. In addition, we have actually made these changes and verified their success with empirical evidence. Yes, the numbers can be imperfect. No, we can't believe everything that Apple tells us. But with the exception of a handful of high disk-intensity apps, this problem can be mitigated for most with a few very simple adjustments. If you already have an M1-based machine and you see high SSD usage, you can either make the changes or take your chances. If you haven't bought one yet, either understand the minor (in the opinion of me and many others) changes and decide if having one is still worth it t you. If not, wait and see. In my case, the changes have done nothing to reduce my user experience or pleasure in day-to-day usage. In fact, in some ways, they have increased both. As always, YMMV. But, I respectfully submit that throwing up your hands and taking the stance that the numbers can't be trusted, or repeating related but not directly applicable information, (the very definition of "fake news"), leads us nowhere.
Last edited:
And nobody has to interpret the NVMe spec anyway because Apple provides an API for reading NVMe SMART data directly. Back some time ago I posted that it was up to the app developer to get the offsets of the data within the block of data returned by IOKit but that was wrong and based on old code in smartmontools meant for other SSDs and HDDs. The code that smartctl is using for reading the SMART data from the M1 is completely documented and supported within macOS Big Sur (and probably earlier). The library calls are straightforward and easy enough for anyone with experience with C or C++ to figure out. If the library functions aren't working correctly, that is fully on Apple for creating buggy software. But I don't believe that. From all my testing, the TBW values are working exactly as expected.
To sum up, Apple wrote the library function used to retrieve SMART data from the M1 SSD controller. They designed the SSD controller. They are clearly using the NVMe spec according to their source code header files. There is no ambiguity about this. I expect the usual suspects will simply ignore all this and continue saying that the data can't be relied on.