[Top] [All Lists]

Re: The XFS real-time subvolume in Linux

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: The XFS real-time subvolume in Linux
From: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 5 Oct 2005 16:58:10 +0200
Cc: Eric Sandeen <sandeen@xxxxxxx>, Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200510051624.16213.ak@suse.de>
References: <BAY110-F272BEC2E5C429160FB4068B4830@phx.gbl> <200510051618.44230.ak@suse.de> <20051005142006.GA3511@suse.de> <200510051624.16213.ak@suse.de>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Wed, Oct 05 2005, Andi Kleen wrote:
> On Wednesday 05 October 2005 16:20, Jens Axboe wrote:
> > Indeed, only for the 'obscure' life-or-death type setups will there be a
> > real difference.
> Even for those you could in theory do bandwidth allocation on top of 
> the RT classes with some tweaking of the time slices and knowing the worst 
> case transfer rate of the HD, couldn't you? Basically it would be an 
> user space problem.

There are still unknowns, the HD still being the biggest one of course.
The problem is that you don't know the worst case HD performance, it
might be doing all sorts of rewriting, calibration, error correct etc
that can still screw you. So I think without definitely knowledge of
what the HD will do in case of errors (or a way to control that which
you definitely can on some drives), it's still pretty hazy. It gets
better, but if you are looking for complete guarantees I don't think
it's good enough.

Jens Axboe

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