Runtime: Developers using FileStream find it to be high performance and robust

[benaadams]

(Note .CopyToAsync is pretty good; for certain combinations of flags)

Issues:

• [ ] Read{Async} and Write{Async} etc call SeekCore which on Windows calls the blocking api SetFilePointerEx which the "Windows Server Performance Team Blog: Designing Applications for High Performance – Part III" (June 25, 2008) says about
  > The old DOS SetFilePointer API is an anachronism. One should specify the file offset in the overlapped structure even for synchronous I/O.
• [ ] Avoid unnecessary allocations when using FileStream #15088
• [ ] Win32 FileStream turns async reads into sync reads #16341
• [ ] Win32 FileStream will issue a seek on every ReadAsync call #16354
• [ ] FileStream.FlushAsync ends up doing synchronous writes #27643
• [ ] Asynchronous random file access with FileStream Read vs ReadAsync in a loop / parallel (ReadAsync is slow) #27047
• [ ] FileStream.Windows useAsync WriteAsync calls blocking apis #25905
• [ ] File.ReadAllTextAsync not behaving asynchronously when called on inaccessible network files #25314
• [ ] Use PreallocatedOverlapped when internal FileStream buffer isn't being used on Windows #25074
• [ ] File.WriteAllTextAsync performance issues #23196
• [ ] Asynchronous FileStream I/O can throw in the completion port callback thread #13658
• [ ] Rosyln has their own workarounds for FileStream issues; and NuGet recently moved to mmap for better performance https://github.com/NuGet/NuGet.Client/pull/3524

_Edit by carlossanlop: To focus on the Async/Sync improvements, I'm removing 3 issues from the list that are separate from that topic._

[danmosemsft]

Thanks for collecting these into an “epic” 🙂 This is a candidate for some code debt work before 6.0 feature work starts.

[danmosemsft]

@JeremyKuhne you've been a vocal advocate of improving FileStream in the past. Is there anything you want to add to this meta-issue?

[carlossanlop]

Thank you @benadams for compiling the list.

May I suggest to focus this epic specifically for improving sync/async in FileStream, which seems to be the main topic of most of those issues? If agreed, then these issues can be removed from the epic and addressed separately:

• https://github.com/dotnet/runtime/issues/8307 FileStream.SetLength doesn't return file pointer to original value on failure.
• https://github.com/dotnet/runtime/issues/29173 FileStream.Lock(Int64, Int64) failure on Linux - always uses F_WRLCK.
• https://github.com/dotnet/runtime/issues/28444 FileStream.Flush(true) doesn't flush device buffer on macOS, while it does so on Windows.

[jeffhandley]

@stephentoub What do you think about #8307, #29173, and #28444 -- do you think those are standalone enough to treat separately from the bigger collection of issues? If so, we can go ahead and get started on those soon.

[stephentoub]

do you think those are standalone enough to treat separately from the bigger collection of issues?

Yes

[danmosemsft]

Changed title to "user story terms" even though it's clearly not describing the current state.

[benaadams]

io_uring for file I/O on Linux? 😉 https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/