Temporary file system filled up C drive

[Entroper]

I'm running with the Creators Update, and I had a Node process hang for a long time. After killing it, I started getting disk space errors in Windows. My %appdatalocal%/lxss/temp folder was full of large (> 20 GB) files.

I couldn't really use my computer at this point, so I deleted those files. And predictably, this broke my WSL installation. Nearly everything I do in WSL blows up with a "cannot create temp file, no such file or directory" error. Is there a way to fix the temp folder so I can use WSL again, or do I pretty much need to start from scratch? And if WSL fills up my C drive again, how can I reclaim the temporary space without breaking it?

[therealkenc]

I don't have any answer to your practical question; hope someone on the team does. See #1740 (message). But for the sake of someone else hitting this, can you share what Node package (particularly any potentially relevant native modules) you are using? When I hear "20 GB files", that makes me wild guess #1732 (message). Not necessarily Flow specifically, but there aren't many use cases for temp files with 20GB of "real" data. Maybe the files are sparse, which take up actual space on WSL but not on Real Linux (in which case you'd never notice them in /temp unless you looked). Again, just a wild guess though.

[Entroper]

Yeah, it was flow. It sounds like you're right, flow uses sparse files and blows up the WSL filesystem. Not cool on a 512 GB SSD.

This at least gives me a suggestion on where to look within WSL for the files. I did look in /tmp before messing around in lxss, but didn't see anything. Yet now, when I look, there are files there, but they're undeletable. I'll probably remove and reinstall WSL shortly, I don't know if this is fixable otherwise. I was very careful not to touch anything outside of lxss/temp, but WSL is having issues with all files, temporary or not.

[therealkenc]

Might be worth posting the issue over with the Flow guys. They ought to be cleaning up their temp turds, at least in non-abort paths. Ten such files isn't cool on a 512GB SSD, but one or two might be semi-tolerable. Not making any excuses for the lack of WSL sparse file support, mind. Just sayin'.

[therealkenc]

@Entroper - Wait... Per your edited second paragraph, I think you might have found a separate bug here; contrast, the lacking sparse file "feature". I believe the real sparse files you are looking for used to live in /run/shm/. But you won't find them there now, because they got unlink()ed right after creation. That directory you cleaned out, .../lxss/temp, doesn't have to do with WSL LxFS /tmp in this context. [I did a double-take on your 'misspelling' when you posted, but didn't know what to make of it at the time.] @SvenGroot explained in #966 (message) that WSL implements open fs handles to unlinked files quote "by renaming the file to a temporary directory". I bet that is .../lxss/temp. So it isn't Flow failing to clean up after itself, as I naïvely went to in my head. It is WSL that is leaving dead soldiers behind. So don't bother the Flow people as I suggested. Their code is fine, and WSL is leaky.

[Entroper]

I don't think it was flow failing to clean up after itself or WSL, I think it was because flow had been running for about 3 minutes, and I killed it. So it couldn't clean up anything.

[therealkenc]

Correct; that is precisely the (WSL not Flow) leak. When the file handle closed on process death (by normal exit or by being shot in the head), the backing store for that unlinked file (with a refcount of 0) should have been released per *nix semantics. The fact that the files are large and sparse just makes them more noticeable. So good catch.

[SvenGroot]

If a file is marked deleted, we do indeed move it to the temp directory, but we also mark it as delete on close. When there are no further references to the file (when you killed Flow), the files should have been deleted. The fact that that didn't happen would indicate a bug somewhere.

[therealkenc]

Yeah, it was flow. It sounds like you're right, flow uses sparse files and blows up the WSL filesystem. Not cool on a 512 GB SSD.

This one was /dupe #1732 but never got marked as such.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!