Question about LSFS size on SSD and sector size

[fanello]

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

[anton (staff)]

150-160 GB should work fine.

We'll pass down TRIM we'll get down the storage stack so you'll have it.

Don't confuse thin-provitioned VHDX layered on top of a storage and actual thin-provisioned storage policy. These are different and have no relation to each other. For most of the setups you should be using indeed pre-allocated VHDX but it's OK to layer them on top of a thin-provisioned storage volumes where LSFS is just an example.

We'll always report 4KB block with LSFS (technically we can do any block size including 512e but that's made out of user control).

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

[robnicholson]

Is it correct, that I should not use thin-provisioning in Hyper-V? I'm using Server 2012 R2.

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.

Cheers, Rob.

[Anatoly (staff)]

Rob, thank you for the input.

fanello, could you please try out the suggested and let us know if it works for you?

[fanello]

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

[anton (staff)]

LSFS has own implementation of TRIM need to check do we pass TRIM down on FLAT. Hold on, I'll bring developers here.

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

[Alex (staff)]

Flat container doesn't translate TRIM commands to underlying storage now.
We are planning to add this functionality during the month.

[fanello]

Thanks, I really love the support here

[Anatoly (staff)]

It is always pleasure to assist you!

[rriiicchh]

Flat container doesn't translate TRIM commands to underlying storage now.
We are planning to add this functionality during the month.

Do you have a timeline for this to be included in the released version?

[robnicholson]

Yes, you always promised TRIM support in v8 so to learn it's not there is a bit of a disappointment.

[anton (staff)]

It's there for LSFS and TRIM / UNMAP is already working for FLAT so we'll have an update for that soon.

Yes, you always promised TRIM support in v8 so to learn it's not there is a bit of a disappointment.

[rriiicchh]

It's there for LSFS and TRIM / UNMAP is already working for FLAT so we'll have an update for that soon.

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)]

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.

It's there for LSFS and TRIM / UNMAP is already working for FLAT so we'll have an update for that soon.

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.

[rriiicchh]

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.

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.

We are looking at putting about 6TB of data on the StarWind array so to give this the headroom that LSFS needs we would be looking for 18TB which is naturally 3 times the cost for SSDs and makes it out of reach.

However if we go for flat disks then we can purchase the 6TB of flash however we would need the trim/unmap commands to get this to a working solution.