OMV into Proxmox, low writing rate

How is the OMV VM configured in Proxmox? Are you working with virtual data disks or passthrough data disks in the OMV VM? What filesystem have you used when formatting the data disks in the OMV VM?

PS Most of that stuff about options to speed up SMB are voodoo or out of date or are even already part of the the global smb config.

So your OMV data disk is a zvol on your zpool mirror which OMV sees as a virtual drive. But what filesystem is used within OMV?

ik3umt I'm waiting for answer to my last question. What filesystem is used within OMV?

Not much point in increasing OMV VM RAM as you will just starve Proxmox itself of memory. Also, if the CPU on your HP micro gen8 has only 4 cores, just use 2 or 3 in the VM and use host cpu. You might as well turn guest agent on in the VM config. (See here if you want to limit the zfs arc memory: https://pve.proxmox.com/wiki/ZFS_on_Linux )

What is Proxmox installed on? Is it the HDD zfs mirror? Really, I don't know what kind of performance you expected with this. It's not really RAM that's the problem, the IOPS of the zpool mirror are low and zvols don't perform that well. Hopefully Proxmox picked the right ashift for you, or something other than ashift=12 will just make things worse. But the OMV VM looks to be using more memory than you might expect, so you going to have monitor the VM from within OMV.

You're writing to a ext4 formatted zvol through the virtualisation layer of the OMV VM. It is going to be slow. Just monitor the writes within OMV, On the proxmox host, something like "watch -n 1 zpool iostat -vly 1 1" will give you an idea of how the underlying zpool performs. You will also see if you are generating a lot of sync writes on your zpool. The way proxmox picks a zvol blocksize is also going to determine the degree of write amplification. Look at the zvol properties on the host.

An alternative is to install Proxmox on a single hard drive, it will use LVM to give you snapshots. Of course the system and any VM will be much slower than using a dedicated ssd. Then just configure proxmox storage on the second drive not using zfs which can be used as virtual drives for any VM.

Or you could go with OMV on baremetal and use KMV within OMV. Disk writes to ext4 on a single HDD will be what you'd expect. But really for any docker/VM work you know SDDs are a better choice.

ik3umt one side to note, strongly rethink putting OMV on a bare machine, do this only if you have straightforward networking, no vlans, virtual nics etc, otherwise you'll need to learn about salt states in omv so it won't overwrite your netplan configs as OMV doesn't provide any gui for this and it will be a pain - trust me, have this problem now, thinking about moving out from OMV from bare machine.

Zitat von lolek

ik3umt one side to note, strongly rethink putting OMV on a bare machine, do this only if you have straightforward networking, no vlans, virtual nics etc, otherwise you'll need to learn about salt states in omv so it won't overwrite your netplan configs as OMV doesn't provide any gui for this and it will be a pain - trust me, have this problem now, thinking about moving out from OMV from bare machine.

Very true. OMV using netplan means no vlan aware bridges and no easy use of ovs , etc. Not surprising really as Proxmox is designed as a virtualisation host with sdn and OMV primarily as a NAS

One option I didn't mention was of course not to use OMV at all. Create your own file server on Proxmox in a lxc container with bindmounts to the proxmox storage. You could, for example, either install and manually configure a samba/nfs server in the os image of your choice, or use a turnkey file server image with webmin, or install and use cockpit in an lxc with some packages from 45drives.

Zitat von ik3umt

Yes OMV is built over Debian, so I think all the network stack (not managed by GUI) has to be managed at machine level ,

yes it can but then you have to fiddle with omv to not break your config if you accidentally touch it in gui, because OMV doesn't care and doesn't check, just overwrite! You'd need to manually add additional settings to omv to preserve your configs.

And then it's a problem because if you have custom configs on network, you can't use them in other places so you're kind of stuck.

Long story short, if you're network is anything bigger than simple one lan few simple nics? Stay away from OMV.

Zitat von ik3umt

Ok , I have OMV on bare metal now.

Transfer rate at full throttle 115 MBps on gigabit ethernet !

And it's consuming 9% CPU and 500MB RAM out of 16GB available....

That's what you'd expect. Writing to a qcow2 virtual disk with ext4 in use on host and in guest is typically 60-80 MBps at best.

OMV on Proxmox should still work. I think the ZFS was limiting. Shouldn't be using it without ECC memory anyway.

Zitat von chente

Whether or not you need ECC memory is not unique to ZFS. It can be applied to any file system. The only difference is that the ZFS documentation placed more emphasis on this aspect and the others did not.

Agree with the first two sentences. 3rd one not so much.

Quote from Joshua Paetzel, one of the FreeNAS developers:

Zitat

ZFS does something no other filesystem you’ll have available to you does: it checksums your data, and it checksums the metadata used by ZFS, and it checksums the checksums. If your data is corrupted in memory before it is written, ZFS will happily write (and checksum) the corrupted data. Additionally, ZFS has no pre-mount consistency checker or tool that can repair filesystem damage. [...] If a non-ECC memory module goes haywire, it can cause irreparable damage to your ZFS pool that can cause complete loss of the storage.

jollyrogr We can go round in circles about zfs & ECC all night if you want to but it's an old cannard and a waste of time. Latest OpenZFS statment is here:

FAQ — OpenZFS documentation

Zitat

Do I have to use ECC memory for ZFS?

Using ECC memory for OpenZFS is strongly recommended for enterprise environments where the strongest data integrity guarantees are required. Without ECC memory rare random bit flips caused by cosmic rays or by faulty memory can go undetected. If this were to occur OpenZFS (or any other filesystem) will write the damaged data to disk and be unable to automatically detect the corruption.

Unfortunately, ECC memory is not always supported by consumer grade hardware. And even when it is, ECC memory will be more expensive. For home users the additional safety brought by ECC memory might not justify the cost. It’s up to you to determine what level of protection your data requires.