Sorry, seems to not be my experience with VEEAM - there's a couple ways to use Veeam with VMWare backups...4x with 4 NICs in 4 subnets and in vmware you feed it the 4 ip addresses of the FN filer when you config a NFS 4 datastore. That is assuming your on the same switch or your cross connected switches have a big pipe/backplane. In VMware you have to tell it that for vlan1 use vnic0 as active and the others as standby and repeat the logic for all threee other NICs.
VEEAM is terrible, they do dirty snapshots. If you do the vcenter integration with FreeNAS even the NFS snapshots are application aware as they chat with the vmware tools.
6.5 has it, though you have to have the right VMFS version; IE, migrate to new datastores.Microbursting (and having switches with big enough buffers) has been the biggest issue I've had with iSCSI, anything this side of a Cisco 4948 i've had underwhelming performance from. FC not so.
The non-automatic unmap I presume you're referring to the VMware limitation in vSphere < 6.5 where you can only unmap from esxcli, they fixed that (iirc) from 6.7 onwards. There's a page on the datastore configuration that lets you enable automatic unmap and set the priority for it, it works for me.
HI Merlin,Just noted that dual port SAS drives will become an enterprise feature, while working perfectly fine with freenas 11.x.
Thanks. Clear.Yes and no. Yes, metdata is permanently attached, and no, the metadata is not backed up to any other storage. You are supposed to create a metadata vdev with a suitable level of redundancy.
The BETA2 release article discusses persistent L2ARC. Does anything need to be set or configured or should it "just work"?I apologize if this has already been asked. I don't see Persistent L2ARC on the feature list. Is that still slated to be included in TrueNAS 12? Is it in the Beta? My understanding is that the Commit has already been merged to OpenZFS Master. https://github.com/openzfs/zfs/pull/9582
ZFS Persistent L2ARC: L2ARC (flash-based read cache) is typically cleared on a controller reboot or failover. For smaller systems with less than a TB of L2ARC, that can be ok. For larger systems with 10TB of L2ARC, it may take hours or even days to rehydrate the L2ARC. The persistent L2ARC option avoids clearing the cache allowing performance sensitive systems to get back to full speed without delay.
ZFS Asynchronous TRIM: OpenZFS 2.0 includes asynchronous automatic and manual trim capabilities. Manual Trims can be scheduled overnight or each weekend to provide more performance during business hours.
It's a "just work" thing, afaik... according to the github discussions with the developers of persistent l2arc :)
Thank you. That was my impression from the PR, but just checking. I’ve been tracking your work on the zstd PR. Awesome contribution. Looks very close.It's a "just work" thing, afaik... according to the github discussions with the developers of persistent l2arc :)
Considering Zstandard compression is most likely to be integrated into OpenZFS2.0 and draid might be integrated into OpenZFS2.0 (depending on review feedback and bug testing), are you guys going to support those features too, or is TrueNAS Core 12 going to ship without actuall support for these key features (if draid makes the cut)?
I'm asking as Zstandard compression wouldn require some significant GUI rework (considering the many levels, you might want to split the compression level from the algorithm selection) and draid would actually require a totally new gui....
Once we get zstandard merged I might look into submitting a PR for the required middleware+gui changes for TrueNAS... But don't hold me to it ;)
Thanks Morgan, my comment indeed wasn't as complete as I would've hoped: It's indeed: "just works, but can be disabled", not just "just works"Persistent L2ARC is expected to get a button because in some cases, users will prefer it is not persistent. It may increase boot time with large L2ARCs.
Manual trim via CLI works fine. Persistent L2ARC doesn't appear to be functioning. L2ARC reset on reboot (see image).Persistent L2ARC is expected to get a button because in some cases, users will prefer it is not persistent. It may increase boot time with large L2ARCs.
Manual trims will be enabled via CLI or script in short term. If someone has a reason to use this, please experiment and provide some feedback.