Page 1 of 1

Long mount time

Posted: Thu Oct 09, 2014 7:23 pm
by Mordock
I just powered on a Starwind VSAN and it took a good 10 minutes for it to mount a couple of LUNs (200GB and 300GB). What can cause this long mount time and how can I avoid it. The delay kept a couple of VMs from powering on via VMware Automatic Startup.

Re: Long mount time

Posted: Fri Oct 10, 2014 9:09 am
by robnicholson
I've observed something similar in the lab. I just put it down to me messing around a lot but maybe not.

Cheers, Rob.

PS. Which version BTW?

Re: Long mount time

Posted: Fri Oct 10, 2014 9:32 pm
by Mordock
Brand new install of the latest 8.0.7145. I just tried a simple shutdown and restart and it took the same amount of time. At this rate a 1TB LUN could take a half hour to mount after every Patch Tuesday. That is not acceptable. There has to be a way to avoid whatever is going on. This is in a lab environment and it is not clustered, nor will it ever be clustered. It will be shut down between uses, cloned multiple times then booted. Whatever it is, I need to find out how to disable it or avoid it.

Is there some special way that I should be shutting it down properly? I generally just use VMware tools to do a proper shut-down. Should I be shutting down the service first? Restarting the service doesn't cause this. I can't find any shut-down procedures or instructions in any of the documentation that I have found online.

Mordock

Re: Long mount time

Posted: Wed Oct 15, 2014 10:52 am
by Anatoly (staff)
Have you configured StarWind LSFS device?

Re: Long mount time

Posted: Wed Oct 15, 2014 1:01 pm
by KLSsandman
We had the same issues, but ours took over 4 hours! (We had 6 lsfs devices). I did hear that there is a patch coming that addresses LSFS issues, I assume this patch will fix this? I hope anyway as we have had to go to no replication and a single flat lump of disk until the patch comes out. We also saw extremely poor read performance (as in vm's were pretty much useless.) It took over 1 week to storage vmotion everything off the lsfs devices onto the single flat lump of disk so we could get some performance again.

This happened around July/August. I keep checking the version number of the website twice a day!

Thanks
Simon

Re: Long mount time

Posted: Thu Oct 16, 2014 10:57 am
by Anatoly (staff)
Well, as you may know lsfs requires improvement, and we are expecting it in couple of weeks.

Re: Long mount time

Posted: Sat Nov 29, 2014 7:23 pm
by Mordock
you think... lsfs needs improvement? I have a 30G deduped lsfs that is taking up 150GB of disk space and is taking 20 minutes to mount. I would go to a raw disk, but although it says all over the web site that the free version has all the features of the paid version except it is limited to 2 nodes, the only kind of disk I can create is lsfs.

I see that there is a new build, 7354. Are any of these problems fixed in this build, the current build thread on this forum has not been updated to reflect this build.

Re: Long mount time

Posted: Wed Dec 03, 2014 11:46 am
by Anatoly (staff)
It still has the issue. Next build that will be uploaded on the website in December should fix the issue.

Re: Long mount time

Posted: Wed Dec 03, 2014 5:02 pm
by Anatoly (staff)
Gentlemen,

Good news! We got the fix in beta build. Please refer to this thread, and let us know if that helped:
http://www.starwindsoftware.com/forums/ ... =17&t=3947

Re: Long mount time

Posted: Fri Dec 19, 2014 7:39 pm
by Anatoly (staff)
Hello everyone! May I wonder if you guys had any chance to test the beta build? Do you have any results to share please?

Re: Long mount time

Posted: Wed Oct 30, 2019 6:35 am
by smcclos
I found a solution to the problem that worked for me. The .000.spvmap file was fragmented. I did the following steps:

-Stop the starwind service
-defrag file *.000.spvmap with systernals tool contig
-Start the starwind service

My startup time went from 4 - 5 minutes to less than 30 seconds.
LUN size: 1.03 TB
Disk Space: 727 GB
Version: 8.0.0.12146

Re: Long mount time

Posted: Fri Nov 01, 2019 2:27 pm
by Boris (staff)
I have had a conversation with the team and it looks like your finding has been confirmed. It may be used for its intended purpose, yet this belongs to the category of workarounds rather than official tweaks.