summaryrefslogtreecommitdiffstats
path: root/sys/netsmb
diff options
context:
space:
mode:
authorphk <phk@FreeBSD.org>2004-03-10 20:41:09 +0000
committerphk <phk@FreeBSD.org>2004-03-10 20:41:09 +0000
commit0f56e66e2f53df9e66c87c4c703a093c7926dc1c (patch)
tree59ebe2a7ed44e7865042f27309af6372e0e6c948 /sys/netsmb
parent1ea153590eb705528aa8cdf33a034b97c6cd57ba (diff)
downloadFreeBSD-src-0f56e66e2f53df9e66c87c4c703a093c7926dc1c.zip
FreeBSD-src-0f56e66e2f53df9e66c87c4c703a093c7926dc1c.tar.gz
Fix a long-standing deadlock issue with vnode backed md(4) devices:
On vnode backed md(4) devices over a certain, currently undetermined size relative to the buffer cache our "lemming-syncer" can provoke a buffer starvation which puts the md thread to sleep on wdrain. This generally tends to grind the entire system to a stop because the event that is supposed to wake up the thread will not happen until a fair bit of the piled up I/O requests in the system finish, and since a lot of those are on a md(4) vnode backed device which is currently waiting on wdrain until a fair amount of the piled up ... you get the picture. The cure is to issue all VOP_WRITES on the vnode backing the device with IO_SYNC. In addition to more closely emulating a real disk device with a non-lying write-cache, this makes the writes exempt from rate-limited (there to avoid starving the buffer cache) and consequently prevents the deadlock. Unfortunately performance takes a hit. Add "async" option to give people who know what they are doing the old behaviour.
Diffstat (limited to 'sys/netsmb')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud