[haiku-bugs] Re: [Haiku] #15585: IO stall for a long time during creation or deletion of many small files
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Thu, 30 Jan 2020 00:29:10 -0000
#15585: IO stall for a long time during creation or deletion of many small files
-----------------------------+----------------------------
Reporter: X512 | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-----------------------------+----------------------------
Comment (by waddlesplash):
Haiku may finished faster because cache was not written to disk at
moment of test complete.
OK, but the same may be true on Windows, right? And the intermediate
"jumps" go over the Windows numbers, so that's a good indication that when
the cache does write back, it's about as fast as Windows.
Try on a RAMdisk and see what performance you get then; that should help
isolate if the I/O stalls are due to the SATA/SCSI stack, or due to BFS
and caching logic itself.
Cache will fill up in any case if disk is slower than sending write
requests.
Yes, and then I'd expect to see the graph "level off" and move at a slower
but constant rate. The fact that it doesn't indicates the write-back code
has bad logic here somehow.
Does somebody know how other OS (Linux, BSD) deal with this problem?
I don't think this is a difficult theoretical problem or anything, there's
just some bug in how we handle deciding what and when to write-back.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/15585#comment:14>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
