Re: [Libvir] Re; virDomainBlockStats
Mmm,
I will have to experiment to see what happens by forcing failures and measuring the damage
..
fyi; I'm pretty much 100% sure aio does not work on "gluster" .. indeed it
seems this may be my "main" problem with aio as now I've moved some testing
kit onto local partitions, I am getting some better results. That said, I'm getting of
the order of within 5% native speed over gluster, which seems to be approaching that of
local partitions ..
(using "file:" .. AND all filesystems were created as sparse ..)
[not really an issue as we *need* a cluster fs for migration]
It sounds like I might have to hack the loopback driver and force a regular sync out of it
.. however, testing first ..
Also (!) our "accidental" policy of storing critical data (DB's etc) outside
of the DomU's on raw network filesystems has probably been rather fortunate ...
:)
Note; my hack to libvirt to work with file: seems to be 100% across my particular platform
...
Thanks,
Gareth.
----- Original Message -----
step 3.: "Daniel P. Berrange" <berrange(a)redhat.com>
To: "Gareth Bult" <gareth(a)encryptec.net>
Cc: "libvir-list" <libvir-list(a)redhat.com>
Sent: 27 January 2008 17:03:09 o'clock (GMT) Europe/London
Subject: Re: [Libvir] Re; virDomainBlockStats
On Sun, Jan 27, 2008 at 02:53:46PM +0000, Gareth Bult wrote:
Ok, question;
Does TAP:AIO work on networked filesystems .. my testing says not.
It does on Fedora / RHEL at least - it should work on any FS that
supports direct IO & async IO.
XEN without a good underlying cluster filesystem is to say the
least "limited". If you can't use AIO in this sort of environment,
it also becomes limited .. and if libvirt requires this, it means
libvirt can't be used on large-scale roll-outs on (certain?)
network filesystems.
We need to fix libvirt so that stats work with file: based devices
too. We just need to figure out the logic required in order to
generate the correct device ID.
Interestingly (looking at the Xen list re; performance problems)
I'm getting > 65Mb/sec on my DomU's .vs. 70Mb/sec on my host
nodes Dom0 ... and it's proving to be reliable atm ..
You ought to be able to get within 5% of host performance when
using either phy: (for real block devs) or tap:aio:. NB make
sure you do *not* use sparse files - fully allocate the file
if you want good performance. Sparse file have terrible performance
characteristics as blocks as allocated on-demand which causes
metadata syncs of the underlying host FS, which serializes all
I/O operations.
Be interesting to know why Xen only documents "file" given
the critical nature / apparent flaws in the driver.
Xen documentation leeaves alot to be desired :-(
Is there "no" way of forcing a loopback interface to flush
itself?
Unfortunately not - its inherant in the impl of loop devices.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|