How long to add a 13TB volume

[implode]

I added a large SAN-backed volume on a VMware FreeNAS deployment. It's very high performance storage. The VM is set to two cores @ 2.3 GHz and 8 GB RAM. FreeNAS has been chewing ~3GHz for 32 hours now with the zpool process at 100%. I presume it's scrubbing/formatting or something? When I click on volumes it just says loading indefinitely. I cannot enable SSH because it says it's busy.

I'm literally just wondering how long to wait or if this is normal.

 

[joeschmuck]

Well I think to get some help you first need to know that FreeNAS is not technically supported on a VM, with that said you are going to need to provide some data about your hardware configuration, FreeNAS version, how you have this 13TB of data connected. Was there data on the storage, what have you done to date?

Lets say you put 13TB of storage into a FreeNAS system, connected them with SATA cables, it would take mere seconds to create the pool. So I'm not sure what you are doing nor what you are expecting to accomplish.

 

[jgreco]

Has the SAN presented itself as SSD storage to FreeNAS?

If so, it's probably UNMAP'ing/TRIM'ing the unused space.

 

[SweetAndLow]

Should be done in seconds. Describe your environment better so we can help you.

 

[Mirfster]

The VM is set to two cores @ 2.3 GHz and 8 GB RAM

Is the VM CPU set to "High" and the "Memory" set to "Reserve all guest memory (All Locked)"? 8GB of RAM seems a bit on the low side to me...

 

[jgreco]

It'd also be helpful to know if the VM was showing lots of storage activity, which I'm guessing would be a TRIM operation.

 

[implode]

The storage, which is a Nimble hybrid iSCSI SAN, is presented as a basic GPT disk via the default LSI Logic SCSI controller. Pretty much chose defaults when it came to adding the disk. It shows up as da1 in FreeNAS. When I attempt to add the volume, I am getting this error in the console and it's at that point that the CPU chugs indefinitely until I reboot the VM.

@jgreco - There's a little I/O at the time of my request and then it stops.
@Mirfster - I am not locking guest memory, but I've never seen that become a barrier to functionality... only performance.
@joeschmuck - There was no data on it, it's a fresh virtual disk on a fresh LUN.

 

[SweetAndLow]

The storage, which is a Nimble hybrid iSCSI SAN, is presented as a basic GPT disk via the default LSI Logic SCSI controller. Pretty much chose defaults when it came to adding the disk. It shows up as da1 in FreeNAS. When I attempt to add the volume, I am getting this error in the console and it's at that point that the CPU chugs indefinitely until I reboot the VM.

@jgreco - There's a little I/O at the time of my request and then it stops.
@Mirfster - I am not locking guest memory, but I've never seen that become a barrier to functionality... only performance.
@joeschmuck - There was no data on it, it's a fresh virtual disk on a fresh LUN.

Are you trying to make a pool out of multiple disks that you are exposing to freenas as a single disk over iSCSI? because if you are you should just stop because this isn't a good setup for zfs.

 

[implode]

I suppose you're right. I'm looking to use FreeNAS as a platform to present this storage via CIFS. I really don't care about ZFS or any of the data protection features.

The use-case here is that we have a colocation needing a CIFS share to do SQL backups to... but the only storage there is two block SANs. No file-level storage. I was hoping to use FreeNAS as a "set it and forget it" CIFS share to do this versus spinning up a Windows VM and having to worry about licensing, patching, added security precautions, etc. All of the data that lands on this FreeNAS share will be replicated to tertiary storage also. This will not be primary storage for anything in production.

 

[SweetAndLow]

Freenas is not going to be the correct solution. You need something that has a native iscsi client, windows seems like the correct solution here especially since you want to share stuff out via smb.

 

[jgreco]

Freenas is not going to be the correct solution. You need something that has a native iscsi client, windows seems like the correct solution here especially since you want to share stuff out via smb.

I'm not sure what you're thinking an iSCSI client would do here. He's talking about the backend storage for VMware. It's mostly irrelevant.

In theory, ESXi can allow a VM to believe that one of its virtual disks is on SSD. This is controlled by, for example, the "virtualSSD" tag in the vmx file, or in some cases automatically:

https://pubs.vmware.com/vsphere-50/...UID-E9E146C9-E99C-4468-B70C-770B83788433.html

 

[jgreco]

By the way, I went and actually did do the experiment this morning, and it seems that like on virtual machine hardware 8 and FreeNAS 9.10, on a datastore that identifies as SSD, you'll get this behaviour.

I imagine you could work around it by setting a loader variable for vfs.zfs.trim.enabled to zero but I didn't try.