The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
fanello wrote:Hi,
I want to create a HA Device on a 480GB Intel DC S3500 SSD.
What is the maximum size I can give the device if I want to use LSFS? If I understood correctly, LSFS device can use 2-3 times more space, than it offers.
So I can not give it a value near the 480 GB. But if I use a thick provisined img, the device will lack the benefits of trim.
What is the best practice here?
Is it correct, that I should not use thin-provisioning in Hyper-V? I'm using Server 2012 R2.
Next question is about the sector size. Intel RSTe tells me, that the physical sector size is 4096 byte, but the logical sector is 512 byte. Which sector size should I choose in Starwind?
Thanks for your help.
Regards
Benny
We use thin-provisioning on v6 for our entire Hyper-V 2012 farm and it works fine. Sure, there will be a performance overhead but it's not visibly effecting our environment.Is it correct, that I should not use thin-provisioning in Hyper-V? I'm using Server 2012 R2.
fanello wrote:Hi,
thanks for your help.
I decided to use thick provisioning, because I need the space. Do you pass down TRIM even with thick provisioning? If I place a vm directly onto my Raid, TRIM is working fine in the vm, if I place it onto the Starwind Volume, TRIM is no longer working.
Using 2012R2 as Hypervisor and 2012R2 in the VM.
Regards
Benny
robnicholson wrote:Yes, you always promised TRIM support in v8 so to learn it's not there is a bit of a disappointment.
Are you able to say when approximately? I may be deploying an all flash solution and in that case flat makes sense as I don't need the benefits of LSFS to speed up the array and can't stretch the budget enough to cover the 2-3x size increase for LSFS.anton (staff) wrote:It's there for LSFS and TRIM / UNMAP is already working for FLAT so we'll have an update for that soon.
rriiicchh wrote:Are you able to say when approximately? I may be deploying an all flash solution and in that case flat makes sense as I don't need the benefits of LSFS to speed up the array and can't stretch the budget enough to cover the 2-3x size increase for LSFS.anton (staff) wrote:It's there for LSFS and TRIM / UNMAP is already working for FLAT so we'll have an update for that soon.
The note about LSFS size increase is in reference to the first post whereby it is recommended to only assign 150-160GB on a disk with 480GB capacity.anton (staff) wrote:This week + some tests so I guess couple of weeks sounds reasonable. Did not get the idea about LSFS size increase as LSFS with enabled dedupe and snapshot offloads keeps LESS flash used.