iSCSI recommended capacity

[James S]

I've configured iSCSI as a datastore for esxi 6. I want to make sure I'm following reasonable practice on disk capacities.

Other posts seem to suggest keeping the total store at less than 60% of capacity (presumably on the FN side)? Should I be focusing on the 59% number here?

Should I be concerned if the the capacity on the esxi side hit 100%? My local backup deletes files as it gets to disk capacity. In other words should I be doing something about keeping a certain amount of free space here?

Thanks!

 

[dlavigne]

From https://www.ixsystems.com/documentation/freenas/11.2-U6/sharing.html#extents:

For performance reasons and to avoid excessive fragmentation, keep the used space of the pool below 80% when using iSCSI. The capacity of an existing extent can be increased as shown in Growing LUNs.

 

[James S]

From https://www.ixsystems.com/documentation/freenas/11.2-U6/sharing.html#extents:

For performance reasons and to avoid excessive fragmentation, keep the used space of the pool below 80% when using iSCSI. The capacity of an existing extent can be increased as shown in Growing LUNs.

Thank you for all the work on the excellent documentation.
I saw this along with various posts some of which talked of 50 or even 60 percent. So good to know that 80% is a safe number. Thanks.

My problem is more of a practical one in reading the GUI. In other words - above:
- the pool is at 20% (so another 60% to go before hitting the ceiling?)
- the zvol is at 59%
Am I reading something wrong here?

 

[HoneyBadger]

Total free space in the pool is what will determine performance. Since you haven't created sparse ZVOLs, you won't have to worry about them growing beyond the pool/dataset capacity - that would cause an inability to write to the ZVOL, not just "bad performance"

As far as the "safe" amount to use, it isn't a "switch" where everything is fine up until capacity X% and then it goes to hell. See the attached/thumbnailed graph from Delphix - free space and pool performance have a direct relationship. The fuller the pool, the slower it goes.



It's also not quite as simple as "total free space" - it has to do with how fragmented that free space is. To overgeneralize, ZFS has to write into free space (since it's "copy on write") and the more fragmented your free space is, the harder ZFS has to work to find it.