Disk Write Exception

My test flight application crashed while doing a disk writing operation. I saw the following error in crash log

1073.76 MB of file backed memory dirtied over 705 seconds (1522.14 KB per second average), exceeding limit of 12.43 KB per second over 86400 seconds\

After a little bit of research I found from Apple documentation that System will throw an exception if disk writes from the app exceeds a certain limit in 24 hours window

[https://developer.apple.com/documentation/xcode/reducing-disk-writes)

But the threshold is not documented. But looking at the crash log we can reverse calculate this threshold as 12.43KB * 86400 ~ 1 GB

Does this means that iOS application won't be able to write data more than this limit (1 GB) per day?

Answered by DTS Engineer in 789222022

Hi,

So, let me clarify a few different points across this thread:

The report usually notes that, although it can be rather subtle. Can someone post an example of this report?

These days we have a few different file formats for storing sample traces (that's the format of the logs you're looking at) but in the original "basic" text format, most developer logs have this field near the top:

`Action taken: none

That means exactly what it sounds like- the system capture the log and then did nothing else. Note that when I say "most developer logs", I can't actually remember ANY developer log that was actually a termination.

But the threshold is not documented. But looking at the crash log we can reverse calculate this threshold as 12.43KB * 86400 ~ 1 GB

The logs are intended to be "self documenting", so the specific limit should be listed in the log. You do see cases like this:

  • iPad14,3 reached 4294.97 writes

Sometimes that's because the limit changed, sometimes it's because the kernel collected the log "again" at some later point. Either way, you should be able to tell the difference using the limit referenced in the log.

Does this means that iOS application won't be able to write data more than this limit (1 GB) per day?

No, in this case it means that an iOS app won't be able to write more than ~1 GB/day... without the system generating a log about it. In more practical terms, the actual threshold is fairly arbitrary- the point of this metric is to help detect cases where unnecessary write are being generated without generating massive amounts of irrelevant noise. In that context, 1 GB/day is a pretty reasonable compromise point, as very few apps "intentionally" write that much data, particularly not "user data" that MUST be written.

Of course, there are absolutely going to be outliers that can easily exceed that limit for perfectly sensible reasons. Your app is a clear example of that.

If you say it does not terminate the app that must be the case, and if it's so, then this is not an issue in cases where the app should be doing that disk intensive tasks.

Yep. In your case, all I would really do is take a quick look at the logs to confirm they show what you're "expecting". In your case, what I'd expect to find is that the writes are all coming from specific "bulk I/O" paths and that's what I found from the spot checking I did. Assuming everything looks normal, then you can just ignore them.


-Kevin Elliott
DTS Engineer, CoreOS/Hardware

Seems like that.

In my case I received various reports:

  • iPad14,3 reached 4294.97 writes
  • iPad7,2, iPad8,7 and iPhone13,4 all reached 1073.74 writes

Nut sure if it is version dependant or maybe storage size dependant but the limit can change.

I've just asked for code-level support to Apple, will update with the response.

Did you get any clear response on this?

Not really, just a template about how to symbolicate and read crash logs. I'm going to contact them again, since I failed to reply the last time and this is still a big issue.

Since the last time, I'm now seeing a new limit of 17.18 GB. The lower end device that reported the issue is an iPhone 13 that has a maximum of 512 GB and on the newer side an iPhone 14 Pro Max that has a minimum of 128 GB, so between 128 - 512 we can get that limit. This means nothing, really, since the 1073 MB limit was reported from an iPhone 15 Pro Max that has at least 256 GB.

To be clear, a good solution for this will be to get something similar to UIApplication.didReceiveMemoryWarningNotification so we can at least prevent the crash and cancel the operation with an explanation to the user.

Many of these ‘crash reports’ are not actually crash reports. That is, a diagnostic report is generated but it doesn’t actually terminate your app. The report usually notes that, although it can be rather subtle. Can someone post an example of this report?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry Quinn didn't received the notification about the new post.

I remember reproducing the crash before but I'll try to reproduce it again tomorrow just to be sure. If you say it does not terminate the app that must be the case, and if it's so, then this is not an issue in cases where the app should be doing that disk intensive tasks.

I'm unable to attach a zip here so I've uploaded some xcdiskwritepoint containing the logs: https://d.keka.io/xcdiskwritepoint.zip

Thanks for taking the time.

Hi,

So, let me clarify a few different points across this thread:

The report usually notes that, although it can be rather subtle. Can someone post an example of this report?

These days we have a few different file formats for storing sample traces (that's the format of the logs you're looking at) but in the original "basic" text format, most developer logs have this field near the top:

`Action taken: none

That means exactly what it sounds like- the system capture the log and then did nothing else. Note that when I say "most developer logs", I can't actually remember ANY developer log that was actually a termination.

But the threshold is not documented. But looking at the crash log we can reverse calculate this threshold as 12.43KB * 86400 ~ 1 GB

The logs are intended to be "self documenting", so the specific limit should be listed in the log. You do see cases like this:

  • iPad14,3 reached 4294.97 writes

Sometimes that's because the limit changed, sometimes it's because the kernel collected the log "again" at some later point. Either way, you should be able to tell the difference using the limit referenced in the log.

Does this means that iOS application won't be able to write data more than this limit (1 GB) per day?

No, in this case it means that an iOS app won't be able to write more than ~1 GB/day... without the system generating a log about it. In more practical terms, the actual threshold is fairly arbitrary- the point of this metric is to help detect cases where unnecessary write are being generated without generating massive amounts of irrelevant noise. In that context, 1 GB/day is a pretty reasonable compromise point, as very few apps "intentionally" write that much data, particularly not "user data" that MUST be written.

Of course, there are absolutely going to be outliers that can easily exceed that limit for perfectly sensible reasons. Your app is a clear example of that.

If you say it does not terminate the app that must be the case, and if it's so, then this is not an issue in cases where the app should be doing that disk intensive tasks.

Yep. In your case, all I would really do is take a quick look at the logs to confirm they show what you're "expecting". In your case, what I'd expect to find is that the writes are all coming from specific "bulk I/O" paths and that's what I found from the spot checking I did. Assuming everything looks normal, then you can just ignore them.


-Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks a lot for the detailed explanation Kevin. For mi this is a case close.

Disk Write Exception
 
 
Q