[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Cheap IOMMU hardware and ECC support importance

  • To: xen-users@xxxxxxxxxxxxx
  • From: Gordan Bobic <gordan@xxxxxxxxxx>
  • Date: Sat, 28 Jun 2014 13:05:11 +0100
  • Delivery-date: Sat, 28 Jun 2014 12:06:13 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

On 06/28/2014 10:32 AM, Kuba wrote:
W dniu 2014-06-28 09:45, lee pisze:

and your workload includes a lot of synchronous writes. But
for that workload you would probably be better off getting an
SSD and using ZFS with ZIL in terms of total cost, performance
and reliability.

SSDs still loose badly when you compare price with capacity.  For what I
payed for the RAID controller, I could now buy two 120GB SSDs (couldn't
back then).  That means two disks more, requiring two more SATA ports
(11 in total), and an increased overall chance of disk failures because
the more disks you have, the more can fail.

I don't know about ZFS, though, never used that.  How much CPU overhead
is involved with that?  I don't need any more CPU overhead like comes
with software raid.

ZFS offers you two things RAID controller AFAIK cannot do for you:
end-to-end data checksumming and SSD caching. If anything happens with
your data on its round trip from the CPU to the disk and back, ZFS will
detect that and, provided you have some redundancy, will correct it.
That feature alone, IMHO, makes reading about ZFS worthwhile. As Gordan
states, ZFS can also cache your data using a small SSD. Oversimplifying,
the size of the SSD might be around the size of your data set.

Just to clarify this point a little - for ZIL (caching sync writes) you only need it to be the size of your typical commit burst size, at the absolute theoretical worst the size of your RAM. For read caching (L2ARC), it can be any size, data that is about to get expired from ARC (what ZFS calls it's cache) will be pushed to the L2ARC. I frequently use a small ARC and a large ZRAM backed L2ARC instead of an SSD.

Moreover, it blends in with xen quite nicely, e.g. using ZFS ZVOLs as
block devices for domUs makes cloning and snapshotting easy (and that's
just for starters).

Indeed, not to mention that it can do block-level deduplication for you. If you are running many VMs with a similar OS (disable prelink on Linux!) this can lead to a massive space saving - but only use it on SSDs - deduplication means almost all operations will converge toward being non-linear, yielding appalling performance on spinning disks. Works extremely well on SSDs, though, and that is where space savings count for 5x more in terms of cost. :)

Cloning comes with it's own problems, though. I tend to avoid it. It means the image that fathered the clones can never be removed. Deduplication and dd-ing the volume across is often a better solution.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.