[DragonFlyBSD - Bug #2845] (Feedback) Hangs using dsched policys other than noop

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #2845 has been updated by dillon.

Status changed from New to Feedback
Assignee set to dillon
% Done changed from 0 to 100

We are going to remove dsched entirely.  It doesn't work well with SSDs and the complexity has made finding its bugs too painful.  Several people have tried over the years.  We will need to rethink the whole disk fairness concept/problem.

-Matt

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12726

* Author: jkolodzi
* Status: Feedback
* Priority: Low
* Assignee: dillon
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account