|To:||Jens Axboe <axboe@xxxxxxx>|
|Subject:||Re: The XFS real-time subvolume in Linux|
|From:||Eric Sandeen <sandeen@xxxxxxx>|
|Date:||Wed, 05 Oct 2005 09:11:10 -0500|
|Cc:||Steve Lord <lord@xxxxxxx>, Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx|
|References:||<BAY110-F272BEC2E5C429160FB4068B4830@xxxxxxx> <p73u0fxz4xa.fsf@xxxxxxxxxxxxx> <4342A2AB.4040700@xxxxxxx> <200510041759.15075.ak@xxxxxxx> <4342AAD3.8060102@xxxxxxx> <20051005084117.GF3511@xxxxxxx>|
|User-agent:||Mozilla Thunderbird 1.0.6 (Macintosh/20050716)|
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|