xfs
[Top] [All Lists]

Re: The XFS real-time subvolume in Linux

To: Eric Sandeen <sandeen@xxxxxxx>
Subject: Re: The XFS real-time subvolume in Linux
From: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 5 Oct 2005 16:13:41 +0200
Cc: Steve Lord <lord@xxxxxxx>, Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <4343DEFE.9010505@xxxxxxx>
References: <BAY110-F272BEC2E5C429160FB4068B4830@xxxxxxx> <p73u0fxz4xa.fsf@xxxxxxxxxxxxx> <4342A2AB.4040700@xxxxxxx> <200510041759.15075.ak@xxxxxxx> <4342AAD3.8060102@xxxxxxx> <20051005084117.GF3511@xxxxxxx> <4343DEFE.9010505@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Wed, Oct 05 2005, Eric Sandeen wrote:
> Jens Axboe wrote:
> >That's exactly why the Linux ioprio stuff has been designed the way it
> >is right now - it's not overengineered for something we cannot support
> >anyways. The CFQ io priorities will work well enough for general use, if
> >you are basing your business on GRIO it's a different game completely. I
> >don't want to add kernel infrastructure for something that is very
> >specialized, especially because the code to do so would be 10 times
> >bigger and more complex that the current stuff..
> 
> Jens, I didn't mean to imply that you -should- have done a GRIO-type 
> design (and I doubt that Steve did, either.)  My only point was that 
> GRIO and ioprio are two different IO control mechanisms.

Oh I agree, was mainly trying to clarify that they pertain to two
different market segments. Sorry if that wasn't clear, it's not a
criticism of GRIO (I don't really know anything about SGI's GRIO).

-- 
Jens Axboe


<Prev in Thread] Current Thread [Next in Thread>