Intermittent Problem with SMB Share

[Matt Brown]

Hi,

I’m sorry I’m not sure this is a Sysprogs problem, but I wondered if anyone on this forum had any insight! 🙂

We’ve been using VisualGDB to perform our cross-platform builds for ages.  I suspect there are different approaches, this is what we do:

• The host is a Windows 10 Pro PC.
• The working copy of our repo is checked out on the local storage of the Windows 10 PC
• The Windows 10 PC shares the working copy using CIFS/SMB1
• We perform a build using Visual Studio and VisualGDB with the compiler running on the target using files that are actually on the Windows 10 PC

The targets doing the actual build are in our server room.  The Windows 10 PC is on my desk in the office.  I’m not sure how many network hops that is, but not many.

2 days ago, I changed the network switch that target machines are connected to.  The old network switch was a dusty 8 port Netgear 1G switch.  I needed another port, so I bought a 16 port D-Link 1G switch; nothing fancy, just the first thing I found on the Internet.

Since changing the switch, I seem to be having problems with the build.  I can start a build and the files will start compiling but I see ‘Resource temporarily unavailable’ messages in the VisualGDB output, something like:

../module:374:10: fatal error: ../module/header.h: Resource temporarily unavailable

Most of the files are fine, and if I start the build again it will work or error on different files.

It feels to me like there’s a problem with the SMB share serving the files the target is asking for.  But, why would changing the switch create this problem?  At the moment, my best idea is to put the old switch back and find a different way to get another port.

Are there any techniques for optimizing the SMB share performance?

Any thoughts greatly appreciated, I understand this is a bit off-topic,

Thanks,

Matt

[support]

Hi,

Sorry, it looks like the SMB connection between the Linux machine and Windows machine fails at some point, but it’s not something VisualGDB can automatically fix.

You can try using the usual white box / black box troubleshooting:

• Capture a WireShark trace of network communication between Linux and Windows and analyze it. It should give a good insight into the cause (some SMB request will be failing with an error), but getting to the bottom of it will be a very tedious task, trying to understand thousands of network packets.
• Alternatively, you can try simplifying the repro. Instead of a build, try reading all sources one-by-one. If it doesn’t trigger anything, do it from multiple threads. Try varying the number of threads, making pauses, etc. If it turns out that some particular pattern triggers the problem (e.g. more than X threads in parallel), you might be able to work around it by tweaking the build process.

[Matt Brown]

Hi,

I’m grateful for your thoughts as I know it’s not a problem caused by SysProgs or VisualGDB. 🙂

I just wanted to check I wasn’t missing anything obvious.

I’ve installed haneWIN NFS Server for Windows and used NFS instead of SMB.  I’ve only done 1 build, but it succeeded.  I have to do the mount on the target manually before I start a build, rather than using VisualGDB to do it automatically, but I can live with that.

I now think the changing the switch was a red herring.  My Windows PC was changed a few months ago, and I now think I hadn’t done any of these builds since then.  Just a coincidence that I changed the switch and then tried to do a build I hadn’t worked on for a while.

Thanks again,

Matt

[Author]

Posts