Update of file size for growing files in Windows

Hi,

Thanks for your question. These two articles may help. https://dell.to/3OSkNTq and https://dell.to/3ylTt9d

Let us know if you have any additional questions.

Thanks Josh, but nothing from either article has helped me. I had already tried oplocks and the other setting doesn't seem to change anything either.

Does anyone else have any ideas?

I assumed you are testing with FQDN and most probably writer and reader clients are on different nodes. Have you seen same problem when writer and reader is connected to the same node?

Good hint. I will check that.

But - why does the problem also occur in my simple test environment with only 1 Node Clusters and without any DNS?
I have set up two new OneFS simulators: one with OneFS 8.0 and one with OneFS 9.2. Apart from configuring the IP addresses and activating SMB and FTP, I have not configured anything else on these virtual clusters.

In my test, I create a constantly growing dummy file directly on the virtual Isilon node via dd. At the same time, I have mounted that node via SMB on my Windows client (on which the simulator VM is also running) and look at the file size in Windows Explorer.

With the OneFS 8.0 node, you can see that in Windows Explorer, the file size of the growing file is updated and changes almost every second.

In the directory of the OneFS 9.2 node, you can see in Windows Explorer that the file size of the growing file changes only very rarely (approx. every 30-60 seconds), if at all. If I refresh the directory (press F5), then I can very rarely update the file size more frequently - but really only very rarely.

I can even do the whole thing side by side in parallel. I made a screen video of it, maybe I'll upload it later.

Is there a reason why you need it to update every couple of seconds instead of every 30-60 seconds?

No, every 1-2 seconds, as Windows apparently does (if everything is working properly), it doesn't have to be. But every 30-60 seconds or even less often is definitely too slow, because then the whole workflow no longer works as planned. This would mean that you would have to set the timeout in the workflow accordingly. And then even really small files would only be copied after this timeout has expired.

@DELL-Josh Cr Actually having file in such time is really important. For me, we are running News TV broadcast services which is critical to be the first on-air while breaking news. 

@Phil2018 you might also check and set client-side cache to no-cache on share settings individually.

isi smb shares modify -- csc-policy {manual|documents|programs|none}

Thank you Ozen for that information about the client-side cache. I will check and play around with that setting.

Our workflow is also a News TV broadcast workflows. Whether a clip goes to the playout after 5 seconds or after 60 seconds plays a decisive role. That is the reason why we cannot set the timeout for the file mover from Isilon to playout so high.

The client side cache settings seem to have no impact on the behaviour.

But I found out some other interesting things in my test setup with OneFS 8.0 and different newer OneFS version (8.1, 8.2, 9.2). OneFS 8.0 uses SMB 3.0.0 while the newer ones use SMB 3.1.1 for the SMB connection between the Windows 10 client and the cluster. The problem occurs with all versions that use SMB 3.1.1. The problem does not occur with the versions that use SMB 3.0.

Then I forced the new OneFS versions that are using SMB 3.1.1 (where the issue occurs) to use SMB 1, more precisely SMB 1.5, by deactivating SMB2 and SMB3 Multichannel. With this, the automatic update of the file size in Windows Explorer does not work, but with every folder refresh (press F5) the file size is correctly updated and displayed. This is also the case when I press F5 every 2 seconds. This is exactly what does not work with SMB 3.1.1.

Therefore, I think that a feature of SMB 3.1.1 is the cause of the error. I can't find out exactly what it is and whether it also occurs with 3.0.2 because I don't have a OneFS version that uses it.

You may want to call phone support and have it escalated as a bug.

Yes, I will do.

But is it also collecting all necessary information and data that the Dell support is able to reproduce the issue. And if we know all possible conditions and facts, we can find a workaround to solve the issue in another way.

@Phil2018 did you get any information or resolution from Support about that particular issue?