-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TarWriter_WriteEntry_LongFile_Tests require 104GB free #77012
Comments
Tagging subscribers to this area: @dotnet/area-system-io Issue Details
example stack
I have 68GB free on this disk (which includes %temp%). The failure is because these are all async tests, so they are running concurrently, requiring 13 * 8 GB = 104 GB which I don't have.
|
I don't understand, why does runtime/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntryAsync.LongFile.Tests.cs Lines 11 to 21 in a41ac2c
|
Seems a lot of people are surprised by this -- xunit/xunit#2003 BTW I was curious how paralleism in xunit works generally. Each class is an implicit collection of its own, and within a collection everything is serial (except async case above) but collections can run in parallel with each other. So |
this should probably backport to 7 (when that opens again - after GA) |
I'm not sure if the link is relevant @danmoseley. They use |
I ran the test locally with a Console.WriteLine at the time the file is created and other when the FileStream is disposed. It seems that for me locally the tests do run serial. @danmoseley could it be possible that the file deletion is no occurring at the moment that the FS is disposed but rather it is being scheduled and that's why you get "System.IO.IOException : There is not enough space on the disk"? We could just catch this one exception, ignore it and continue execution.
|
It should get deleted as soon as it gets disposed (https://stackoverflow.com/a/1895066/5852046). The question is when does it get disposed?
runtime/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntryAsync.LongFile.Tests.cs Lines 23 to 24 in a41ac2c
Later the runtime/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntryAsync.LongFile.Tests.cs Line 36 in a41ac2c
So the quesiton is whether the disposal of |
It is not disposing it, but it should. So Alternatively, we can manually dispose the FileStream after we are done with TarReader if we don't want to block on fixing the TarReader.Dispose bug. Great question, Adam. |
Otherwise multiple tar files could stick around for some time, contributing to issues like dotnet#77012
Even with the correct disposal it takes around 10 minutes to execute single test case (#79920 (comment)). We either need to optimize these tests, reduce the number of test cases or just turn them into manual tests that are not included in |
The disk space issue was fixed, we already have one tracking the timeout issue here so closing this: #79773 |
example stack
I have 68GB free on this disk (which includes %temp%). The failure is because these are all async tests, so they are running concurrently, requiring 13 * 8 GB = 104 GB which I don't have.
edit: actually there are 10 async tests, so 80GB, but the non async tests run concurrently, so at least 88GB plus some margin is required.
The text was updated successfully, but these errors were encountered: