Page 1 of 1

Memory calculator/v8 is unrealistic

Posted: Tue Mar 25, 2014 3:00 pm
by robnicholson
I asked about deduplication calculator but I now realise we need the calculator for thin disks as well as it forces a certain cache size and you're unable to specify the cache yourself. I just tried creating a small 1TB drive and it needed ~8GB

One our primary system, we have 3 x 32TB thin provisioned drives as it's suggested you overcommit with thin-provisioning (why not eh?) and this works fine on our existing StarWind system with just 32GB of RAM (and monitoring on the free disk space). For StarWind 8 in the same configuration we're going to need a totally unrealistic 720GB in the SAN!! That's more than all our production servers added together.

>StarWind is primary VM workload

I beginning to think this will be the end of our use of Starwind - or at least we'll not be upgrading. Are you going to continue maintenance of v6? If not, when you need to let us know as we can play to migrate elsewhere.

You appear to have become fixated with VM workload & performance which while important, isn't the only SAN requirement IMO. I said much the same with the deduplication engine.

Cheers, Rob.

Re: Memory calculator/v8 is unrealistic

Posted: Tue Mar 25, 2014 3:02 pm
by robnicholson
Ohh yes, and that memory requirement is just for metadata cache. One needs to add on the read/write cache.

Cheers, Rob.

Re: Memory calculator/v8 is unrealistic

Posted: Fri Mar 28, 2014 6:00 pm
by Alex (staff)
1. V6 will be supported after v8 release.

2. Yes, current implementation of LSFS does have such requirements. This is because it operates with much smaller blocks, 4kB vs 4MBs in thin provisioning of v6.
LSFS supports larger block sizes, and memory requirements are significantly lower for LSFS with large block size. We are still working on this configuration, so it is not available yet.

Re: Memory calculator/v8 is unrealistic

Posted: Mon Mar 31, 2014 1:24 pm
by cphastings
Alex, will this larger LSFS block size be ready before RTM/GA?

Re: Memory calculator/v8 is unrealistic

Posted: Thu Apr 03, 2014 1:16 pm
by Alex (staff)
Most likely this functionality will not be available with the first release of v8, but it will be added in later updates.

Re: Memory calculator/v8 is unrealistic

Posted: Thu Oct 30, 2014 11:34 am
by kaya67
I found out that it wouldn't download the image from that url. I downloaded it manually and pointed to the iso and now it installed, but I had to go into the console of the vm and accept installing the starwind software.
Another problem I had was that when I try to edit settings in the vsphere web gui of the vm to point to another disk and adjust cpu/mem it fails. As it is installed with hw version 10 I have to use the web gui to change settings.

Re: Memory calculator/v8 is unrealistic

Posted: Thu Oct 30, 2014 5:14 pm
by anton (staff)
You should not be using Beta version anymore. We'll explicitly kill all the links. Release was months ago.
kaya67 wrote:I found out that it wouldn't download the image from that url. I downloaded it manually and pointed to the iso and now it installed, but I had to go into the console of the vm and accept installing the starwind software.
Another problem I had was that when I try to edit settings in the vsphere web gui of the vm to point to another disk and adjust cpu/mem it fails. As it is installed with hw version 10 I have to use the web gui to change settings.

Re: Memory calculator/v8 is unrealistic

Posted: Mon Jan 18, 2016 4:27 am
by fbifido
Alex (staff) wrote:1. V6 will be supported after v8 release.

2. Yes, current implementation of LSFS does have such requirements. This is because it operates with much smaller blocks, 4kB vs 4MBs in thin provisioning of v6.
LSFS supports larger block sizes, and memory requirements are significantly lower for LSFS with large block size. We are still working on this configuration, so it is not available yet.
Any update on #2 above ?

Thanks

Re: Memory calculator/v8 is unrealistic

Posted: Mon Jan 18, 2016 12:41 pm
by anton (staff)
We decided to keep blocks native 4KB everywhere (too much of an overhead for read-modify-write doing bigger ones) but we off-load now hash tables and some extra stuff to NVMe flash instead of using RAM for it (similar to flash-based ZIL in ZFS).

First version should be available pretty soon.
fbifido wrote:
Alex (staff) wrote:1. V6 will be supported after v8 release.

2. Yes, current implementation of LSFS does have such requirements. This is because it operates with much smaller blocks, 4kB vs 4MBs in thin provisioning of v6.
LSFS supports larger block sizes, and memory requirements are significantly lower for LSFS with large block size. We are still working on this configuration, so it is not available yet.
Any update on #2 above ?

Thanks