[pve-devel] ZFS Storage Patches

Michael Rasmussen mir at datanom.net
Fri Mar 14 18:52:17 CET 2014


On Fri, 14 Mar 2014 10:11:17 -0700
Chris Allen <ca.allen at gmail.com> wrote:

> > It was also part of latest 3.1. Double-click the mouse over your
> > storage specification in Datacenter->storage and the panel pops up.
> > Patched panel attached.
> 
I forgot to mention that at the moment the code for creating ZFS
storage is commented out
in /usr/share/pve-manager/ext4/pvemanagerlib.js line 20465-20473

> 
> No I haven't.  As far as I understand it sparse should not affect
> performance whatsoever, it only changes whether or not a reservation is
> created on the ZVOL.  Turning of write caching on the LU should decrease
> performance, dramatically so, if you do not have a separate and very fast
> ZIL device (eg. ZeusRAM).  Every block write to the ZVOL will be done
> synchronously when write caching is turned off.
> 
I have already made some test and I have not be able to make any
conclusive tests proving performance should be hurt by using sparse. Is
sparse a way to provision more than a 100% then?

> I've done some testing with regards to block size, compression, and dedup.
>  I wanted sparse support for myself and I figured while I was there I might
> as well add a flag for turning off write caching.  For people with the
> right (and expensive!) hardware the added safety of no write caching might
> be worth it.
> 
I have done the same. For me 8k block size for volumes seems to be given
more write speed. Regards write caching: Why not simply use sync
directly on the volume?

> Have you tested the ZFS storage plugin on Solaris 11.1?  I first tried
> using it with 11.1, but they changed how the LUN assignment for the views
> works.  In 11.0 and OmniOS the first available LUN will get used when a new
> view is created if no LUN is given.  But in 11.1 it gets populated with a
> string that says "AUTO".  This of course means PVE can't connect to the
> volume because it can't resolve the LUN.  Unfortunately I couldn't find
> anything in the 11.1 documentation that described how to get the LUN.  I'm
> assuming there's some kind of mechanism in 11.1 where you can get the
> number on the fly, as it must handle them dynamically now.  But after a lot
> of Googling and fiddling around I gave up and switched to OmniOS.  I don't
> have a support contract with Oracle so that was a no go.  Anyway, just
> thought I'd mention that in case you knew about it.
> 
> In addition to that problem 11.1 also has a bug in the handling of the
> iSCSI feature Immediate Data.  It doesn't implement it properly according
> to the iSCSI RFC, and so you need to turn of Immediate Data on the client
> in order to connect.  The patch is available to Oracle paying support
> customers only.
> 
I have made no tests on Solaris - licens costs is out of my league. I
regularly test FreeBSD, Linux and Omnios. In production I only use
Omnios (15008 but will migrate all to r151014 when this is released
and then only use LTS in the future).

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
I never failed to convince an audience that the best thing they
could do was to go away.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20140314/ff047ca7/attachment.sig>


More information about the pve-devel mailing list