Revit hangs when saving large file to Unraid share

It it's just with Revit it probably won't be easy to help, were the diags downloaded when you were experiencing the non responsive Revit? If not please post new ones so we can at least see if Unraid is doing anything during that time.

Here are the diagnostics from while Revit was unresponsive.

 

For what it's worth, the problem can be reproduced using the trial versoin of Revit 2021 and the included Sample Services example file.

 

https://www.autodesk.com/products/revit/overview

 

(Open Revit, open Sample Service file from welcome screen, save as to unraid share, saves completes but then Revit hangs for 30s. This is only a 29Mb file - most of our files are 100-200Mb, hence the long hang times).

 

dmserver-diagnostics-20200512-1344.zip

This issue really should have been opened under general support. This isn't a bug.

 

> Are there some settings we can try?

 

- Under network settings disable bonding and set a MTU size of 1500 bytes

- I also recommend you disable the setting "Host access to custom networks" (see Docker settings)

 

 

 

Thanks for replying. It's appreciated.

 

The reason I posted it under bugs, is that this is clearly not expected behaviour, although I am happy to admit it could either be Revit or Unraid at fault. Given that the behaviour is only observed when Revit saves to Unraid, and is absolutely fine when saving to (eg) windows share, Sharecentre etc, and I haven't found any other reports of Revit behaving like this, my suspicion lies with Unraid, but it's only a suspicion. What the mechanism might be though I'm not sure. I guess there is some diffference between Unraid and a pure windows share (as experienced by Revit) that is causing the problem).

 

I've tried those suggestions on the Arch server, but unfortunately they didn't help. The other server exhibits the same behaviour and already had those settings set.

 

I'd be grateful if there are any other suggestions (disk tuning settings?? etc) or possible diagnostic approaches I could try.

> I am happy to admit it could either be Revit or Unraid at fault.

 

It could be (and usually is) a configuration mismatch.

 

> I've tried those suggestions on the Arch server,

 

My suggestions are for the Unraid server.

Especially the MTU size, because my suspicion is the current MTU size on your Unraid server of 1986 bytes is causing the behaviour you see.

 

Sorry, I should have been clearer - I tried those settings on the architecture Unraid server, and it didn't help (although it was strange the the MTU was 1986, I hadn't set it to that). 

But the other (Unraid) server also had those settings (unbonded, mtu to 1500, no host access) and it was exhibiting exactly the same behaviour.

 

My concern is that two different servers, on two different networks, with two differenet clients, are showing the exact same behaviour. Of course, I'm the common factor, so it could be something I've done, but apart from the host access setting, the architecture Unraid configuration is pretty vanilla.

Did you fill in an MTU size (overwrite the text in blue) ?

Not when I originally configured the server, but yes when you suggested it. Behaviour still the same unfortunately. See attached for latest diagnostics.

root@dmserver:~# ifconfig eth0
eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether 90:2b:34:52:99:35  txqueuelen 1000  (Ethernet)
        RX packets 159919875  bytes 28388361452 (26.4 GiB)
        RX errors 0  dropped 14  overruns 0  frame 0
        TX packets 195545365  bytes 278563143532 (259.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

and with attachment

dmserver-diagnostics-20200512-1701.zip

6 hours ago, robest said:

the problem can be reproduced using the trial versoin of Revit 2021 and the included Sample Services example file.

Did just that and can confirm I can reproduce your issue, looks to me like Revit is doing sync writes, and this appears to confirm it:

 

https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Revit-slow-saving-to-SMB-share.html

Since it's a Revit known issue going to downgrade this for now, and I don't think LT can do anything about it, but lets see.

Ok. Many thanks for looking in to this. What’s the implication for me though? All out of luck using Revit with unraid? Don’t understand why the performance is fine with a normal Windows share or with our old DLink sharecentre nas...

Changed Status to Open

Changed Priority to Minor

1 minute ago, robest said:

What’s the implication for me though?

With sync writes it will always be extremely slow, because the write itself is much slower than normal and you don't get the cursor back until it finishes flushing all data to the array, either sync writes can be disable or you'd need to use a different protocol like nfs (which I'm not sure it's still supported by Windows).

 

Ok, I get that the sync write is slower, but not why it’s slower on unraid vs the other NAS (given that the unraid box has the ssd cache). Does the sync write bypass the ssd cache? Do I assume that the sharecentre nas had sync writes disabled? How do I disable sync writes on Unraid?

 

sorry for all the questions, just need to work out what to do in the office tomorrow now that our shiny new server is performing much worse than the crappy old sharecentre NAS!!

29 minutes ago, robest said:

but not why it’s slower on unraid vs the other NAS

Likely the other NAS is not honoring the requested sync writes, try this, stop the array and go to Settings -> SMB -> SMB Extras and add:

 

[global]
strict sync = no

 

See if it makes a difference.

 

Unraid has the ability to set specific SMB parameters (see Samba extra configuration).

I don't know if such a solution exists, but you could try to search for SMB specifics with Revit.

@johnnie.black are you paranormal? 

 

Ha. I had got as far as 'strict sync = no' and was just trying to work out where to set that in Unraid / if it was safe...

 

Will try it now.

Yep. That's fixed it.

 

Obviously disabling write through is not ideal, but it's no worse than what they've been using for the last five years on the ShareCentres.

 

Many thanks for your help - it's much appreciated.

Apologies for raising as Bug, grateful that we got to the bottom of it.

 

Cheers

Rob

25 minutes ago, bonienl said:

@johnnie.black are you paranormal? 

No, but I've been told I'm not "normal"

 

6 minutes ago, robest said:

Yep. That's fixed it.

Good, IIRC older Samba releases defaulted to "strict sync = no", newer Samba defaults to "yes" so it honors sync writes/write trough if requested, but as long as you have a UPS you should be fine without sync writes.

 

 

Changed Status to Closed

Changed Priority to Other