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

[Gordan Bobic <gordan@xxxxxxxxxx>]

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.
Gordan


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users