From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Pepper Subject: Re: Re: fastfail operation and retries Date: Wed, 27 Apr 2005 15:57:09 -0700 Message-ID: References: <20050421222409.GY17315@marowsky-bree.de> <20050427144406.GK4431@marowsky-bree.de> Reply-To: Tim Pepper , device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20050427144406.GK4431@marowsky-bree.de> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Lars Marowsky-Bree Cc: device-mapper development , tranlan@us.ibm.com, Linux SCSI , aherrman@de.ibm.com List-Id: linux-scsi@vger.kernel.org On 4/27/05, Lars Marowsky-Bree wrote: > User-space needs to take action and tell us when to stop queuing. Is there any risk of priority inversion? I can't think of a specific issue beyond the userspace daemon process simply not existing that wouldn't hopefully settle out over time and I haven't looked closely at this aspect of 2.6, but it used to be easy to get/keep the cpu busy enough on flushing IO to disk to hurt userspace response times (fibre pulls during heavy buffered, filesystem IO effectively DoSing the machine for a long period). If that sort of thing is still possible, it seems risky relying on a userspace application for timely/meaningful recovery of the resources consumed by the IO.