StarWind Software

Hi there,

we had this LSFS bug last year which filled our disks with .spspx files constantly.
A short time after that a new build with a fix came out. So this is no issue anymore.

We use a roundabout 13 Terabyte Near Line SAS RAID5 Volume for a LSFS LUN without deduplication and StarWind VTL on top to backup our VMs with DPM 2012 R2. (I would say dedup with slow Near Line disks is not a good idea.)

I know it´s normal that a thin provisioned LUN does not shrink itself. I made a full backup for some VMs and the new LSFS LUN was filled with 500GB backup data after that.
I deleted all the backup data and started the backup of one single VM with about 45 GB.
Now the RAID volume was filled with 506 GB of spspx files. 6 GB more data although 45 GB are much smaller than the already growed and "empty" 500 GB.

The first questions is: When and how does StarWind defragmentation work? I read in your FAQs that this feature "clears up" the .spspx file structure to reclaim disk space.
But I can´t see any disk space reclaiming, even when I start defragmentation manually.

You say that LSFS needs 2.5 to 3 t imes more space than you can actively use. Is this still correct?
How much space do I really have to calculate? Is there a point where the LSFS device does not grow anymore?

Actually we have 700 GB filled with .spspx file on the LUN RAID volume and only 50 GB actively used in the LUN.
Let´s say we would backup another VM with 30 GB the RAID volume would fill again with some GB of .spspx files.

What happens when the RAID volume has reached its capacity? Does LSFS clear the .spspx files up? Or does this lead to a functional stop of the LSFS device?

Thanks in advance for any help!

Regards

As far as I know there is no changes in LSFS architecture.
And in release notes there is nothing about LSFS.
I hope there will be some changes, but they are not in this build.

@clickmaster, do you have any additional questions?

What does the 2,5 to 3 factor mean for "real" life ?

Example:
- 6 TB NTFS Volume for LSFS-placement
- you should never define the LSFS volume/device greater than 2 TB on top of 6 TB NTFS volume ?
- because LSFS consums up to 6TB with .spspx files in production ?

So (in this example) there is the choice between capacity (flat -> 6TB usable) and performance (lsfs -> 2TB usable) ?

thanks for answer ...

I think it depends on your storage(HDD`s)

If you have enough performance on your drives, I would choose flat files.

Anyway, choosing HDD`s for your production, you should look into your possible options.

gubru wrote:What does the 2,5 to 3 factor mean for "real" life ?

Example:
- 6 TB NTFS Volume for LSFS-placement
- you should never define the LSFS volume/device greater than 2 TB on top of 6 TB NTFS volume ?
- because LSFS consums up to 6TB with .spspx files in production ?

So (in this example) there is the choice between capacity (flat -> 6TB usable) and performance (lsfs -> 2TB usable) ?

thanks for answer ...

1) 6TB NTFS and only up to 2TB usable with LSFS, is this with or without dedup?
2) Is Starwind looking at how to fix this lsfs problem?
3) Does dedup & auto-defrag works on Flat?

Thanks.

Dedup helps, but if you have a lot of similar data.
As I can see, LSFS technical description is the same for new version https://knowledgebase.starwindsoftware. ... scription/

As far as I know, flat devices doesn`t have a dedup.

1) It's not like he thinks... LSFS will give away space back after scrubber process will gather all garbage and leave unused blocks / technical snapshots.

2) It's not considered to be a "problem". You should really understand what you're doing and what for. You leave us place to store transactions, if there's no place you don't do LSFS. Nimble and NetApp do exactly the same you just don't see amout of the free space on the volumes. BTW, ReFS by Microsoft isn't different: if it's working in a logging mode free space on volume goes up and down during the work, they just give background collector a very high priority so you won't jump from the windows.

3) There's no deduplication with flat images (unless you layer them on top of a dedupe-enabled NTFS but in this case StarWind has nothing to do with dedupe, it's all MSFT).

fbifido wrote:

gubru wrote:What does the 2,5 to 3 factor mean for "real" life ?

Example:
- 6 TB NTFS Volume for LSFS-placement
- you should never define the LSFS volume/device greater than 2 TB on top of 6 TB NTFS volume ?
- because LSFS consums up to 6TB with .spspx files in production ?

So (in this example) there is the choice between capacity (flat -> 6TB usable) and performance (lsfs -> 2TB usable) ?

thanks for answer ...

1) 6TB NTFS and only up to 2TB usable with LSFS, is this with or without dedup?
2) Is Starwind looking at how to fix this lsfs problem?
3) Does dedup & auto-defrag works on Flat?

Thanks.