[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