Sounds like this warning itself is causing a lot more slowdown than what it’s warning about. Can we please disable it?
You can disable the warning by editing C:\Program Files\Unity\Hub\Editor<unity_version>\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\Emscripten\src\library_fs.js around line ~496, delete line
console.log(‘warning: ’ + FS.syncFSRequests + ’ FS.syncfs operations in flight at once, probably just doing extra work’);
For any one on macOS (like me) wondering where this file is:
/Applications/Unity/PlaybackEngines/WebGLSupport/BuildTools/Emscripten/src/library_fs.js
Commenting out lines 495-497 does the trick.
As a potential help to others who may be googling this:
I had the same problem. Things fine in the editor, crash in WebGL, when turning on the warnings things worked fine with the error “FS.syncfs operations” as described here.
I had been using a .Find on a game object (I know I know). But, that game object was not there because I had moved things around and renamed stuff. Getting rid of my bad .Find fixed things right up. Really wish there would have been some kind of error telling me what I had done.
I see this warning as well. If this should not be a warning, how about not use the word ‘warning’ in the log, or better yet, how about Unity get rid of that message unless you can give concrete documentation on why this message is something we should act on and how.
HOW ABOUT YOU READ UP - ABOUT 3 MESSAGES.
since we all so keen to be shoutily telling other what to do.
jukka_j
![]()
Unity Technologies
States very clearly what it is - why it is - and what you can do.
Got the same error on Unity 2019.4, any update ?
In our game, the number of FS.syncFSRequests increases continuously (up to the thousands over an hour or so). Is that also expected or are we leaking something?
I solved the issue by just limiting the FPS to 30p/second.
Application.targetFrameRate = targetFrameRate;
Be wary of setting Application.targetFrameRate on WebGL, as it causes other issues:
Same warning, and nothing loads, stuck on the black screen.
Initialize engine version: 2021.3.16f1 (4016570cf34f)
[UnityCache] 'http://localhost:8000/Build/WebGL.data' successfully revalidated and served from the indexedDB cache
WebGL.loader.js:80
warning: 2 FS.syncfs operations in flight at once, probably just doing extra work
printErr @ WebGL.loader.js:80
syncfs @ WebGL.framework.js:5329
sync @ WebGL.framework.js:1641
(anonymous) @ WebGL.framework.js:1650
setInterval (async)
setInterval @ WebGL.loader.js:66
_JS_FileSystem_Initialize @ WebGL.framework.js:1649
$main @ WebGL.wasm:0x22d13c5
(anonymous) @ WebGL.framework.js:1060
callMain @ WebGL.framework.js:18515
doRun @ WebGL.framework.js:18558
run @ WebGL.framework.js:18570
runCaller @ WebGL.framework.js:18498
removeRunDependency @ WebGL.framework.js:1015
(anonymous) @ WebGL.loader.js:1104
I’ve been hit by this bug as well and tracked the problem down to the sync(onlyPendingSync) method inside .../WebGLSupport/BuildToos/lib/FileSystem.js
The problem is when the onlyPendingSync parameter is true, the method is supposed to only run if there were syncRequests pending while a previous sync was running. The solution is to ensure that in addition to having pending syncs, it should also ensure that the ongoing fsync is not running. Here’s a patch that should fix the problem:
--- old/FileSystem.js 2023-04-18 15:23:34.885222700 +0200
+++ new/FileSystem.js 2023-04-18 15:24:12.256876100 +0200
@@ -7,7 +7,7 @@
sync : function(onlyPendingSync)
{
if (onlyPendingSync) {
- if (fs.numPendingSync == 0)
+ if (fs.syncInProgress || fs.numPendingSync == 0)
return;
}
else if (fs.syncInProgress) {
Edit: Regarding whether this bug is harmless, it seems that it could be serious, as the original pending/inProgress hack is to work around a potential memory leak inside indexedDB, according to a comment in that file:
else if (fs.syncInProgress) {
// this is to avoid indexedDB memory leak when FS.syncfs is executed before the previous one completed.
fs.numPendingSync++;
return;
}
Update 05.15 I submitted a bug report with this patch, which got rejected without consideration due to not being “reprducible” I replied with a link to this thread.
It happens on all our WebGL builds, a lot. Very reproducible.
We can’t edit this file as we use Cloud build.
Seems like no body is working on this…
I also encountered the same problem. I solved it by turning off parallel download tasks.
I guess if Unity WebGL has multiple tasks in IO or IndexDB processing at the same time, this log will be issued. Such as downloading files in parallel, resulting in parallel writing to IndexDB.
I changed the parallel download to serial and there is no such log
I audited the code path in question in detail today, and even though there was an old comment about a memory leak, that comment was stale from nearly a decade ago.
The message can be safely ignored, or if you would like to remove it, the earlier post helps to do that.
The root source of the “X FS.syncfs operations in flight at once, probably just doing extra work” message comes from an external codebase that is not authored by Unity ( emscripten/src/library_fs.js at c47ab8d7f644c6a501a0fc0eeb91f60c5b6682cb · emscripten-core/emscripten · GitHub ), which is why controlling it in-house has had such friction for a long time.
However you all do bring up good points that the message should not be posted in the first place if it does not mean anything, since it will then be just a red herring to diagnosing some other more important issues. I have now authored a fix PR that will clean the warning away altogether, that should help resolve this topic for good. Thanks for persisting with the comments!
Running LTS 2021.3.16f1 and this is till a problem. As a developer I don’t understand how hiding the error can ever be considered a fix.
Just because the error is in a 3rd party library, does not remove the responsibility of the consumer (Unity), distributing it.
This bug is so old and there is even a fix for it posted. But us using Cloud Build can’t leverage from that.
I strongly suggest that Unity pick this up and resolve it, either by addressing to the vendor of the third party library, contributing or deploying the above fix to Unity distributions.
We get this error massively. The console is spammed heavily, so it is a “biggy”.
Where do you configure parallel vs. serial download?
Please someone answer, i’ve been searching in google for this parallel download tasks or parallel download to serial and nothing appears…
I found this: https://docs.unity3d.com/Manual/JobSystemParallelForJobs.html
But doesnt show how to disable, just to create