[Top] [All Lists]

Re: Poor VMWare disk performance on XFS partition

To: Linux XFS <xfs@xxxxxxxxxxx>
Subject: Re: Poor VMWare disk performance on XFS partition
From: pg_xfs2@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Mon, 24 Mar 2008 15:24:46 +0000
In-reply-to: <47E7B3E4.1020205@xxxxxxxxxxx>
References: <876423.51989.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0803240126501.4354@xxxxxxxxxxxxxxxxxx> <47E7B3E4.1020205@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
>>> On Mon, 24 Mar 2008 09:00:04 -0500, Russell Cattelan
>>> <cattelan@xxxxxxxxxxx> said:

>> [ ... ] Mount XFS partition with "nobarrier" option. [ ... ]

> I can verify that ... barriers are killers when running vmware
> guest disk/memory images. [ ... ]

But of course running VM images with 'nobarrier' is quite brave:
because it removes *any* integrity guarantee to IO initiated
inside the virtual machine.

This is because the only safe behaviour for a virtual machine
software is to turn all VM storage operations into synchronous
ones (or else detect the use of barriers inside the virtual

Of course this is going to be catastrophic with XFS's delayed
allocations, which relies on large numbers of outstanding writes
to coalesce them into large segments.

> [ ... ] The preallocation would also help out quite bit if you
> don't mind dedicating the disk space vs the sparse file method,
> which allow for over subscribing the physical space. [ ... ]

But sparse files are a crazy idea for virtual machines, because
the software inside is built on the idea that its storage is
allocated in contiguous volumes, and relies on that for its own

Or else one ends up with a CP/CMS situation where the "CMS"
inside the virtual machine is fully aware that it is running
inside a virtual machine and passes "out-of-bandwidth" hints to
the virtual machine software.

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