Decompressing a zip on a share, to the same share causes network to drop. Present in all of version 11 (11.1-U7, 11.2-U2-U2.1, and newest 11.2-U3

[krakah]

https://imgur.com/a/Ix583TW

https://imgur.com/a/ddKAp2C

In the screenshots there is an iso of Windows Server 2019 in a zip sitting on a windows share at \freenas\media. Opening that zipfile and decompressing it to the same location. The network starts out fine, then gradually gets unstable, and finally just completely drops.

I pulled my hair out for about 2 weeks trying to figure out what was wrong with this while running U2 and U2.1. I was hopeful U3 would fix this, but it does not. Even downgraded back to V11.1-U7 and this is still present.

I dont want to be THAT guy, but I'm ruling out hardware because the same scenario plays out just fine when I install a windows system on the freenas box.

i3 3.7Ghz, 16GB RAM (ran through a memtest). 3x10TB --> Lsi 9211-8i. Intel Dual NIC (non LAGG only using a single interface) with on-board RealTek's disabled (though behavior is the same with any NIC used). Screen console repeats Watchdog Timeout. No error messages on syslog server.

 

[Mr. Slumber]

Hi, did you try the same from a Linux machine? Did the network traffic also come to a halt? I get the feeling that this maybe is more a Windows related problem but it's just a feeling. Maybe I'm wrong.

Here is a post which is not exactly your problem but maybe it can point in the right direction.

 

[krakah]

I have not tried to do the decompress from a linux machine. I don't have any of those.

For the record its the FreeNAS's network that drops, not the Windows machine. After the network completely goes down only a reboot on FreeNAS will bring the interface back up.

That thread doesnt seem to be similar. The OP is looking for a way to save time to just have FreeNAS decompress the archive, rather than having to do it through the share. Hes trying to do exactly what I'm doing but form the looks of it hes actually able to do it successfully. Whereas I am not. I have an application that pulls down files in zip format and then decompresses them. I'm not really interested in doing some non-standard workarounds for what should be a basic function.

 

[Ericloewe]

What happens if you decompress it with 7-Zip or some other tool?

 

[krakah]

The aforementioned software thats downloading the zip is sabnzbd. This isnt in a jail local to to FreeNAS. Its running on a windows VM on a different machine than the FreeNAS box. I don't believe it uses the built in windows zip component as it can decompress rar. Though I'm not exactly sure what it uses. Whatever the case the same behavior occurs when sabnzbd also tries to extract a file.

The screenshots above were just simulating the issue in a faster manner but both ways produce the network drop.

 

[Ericloewe]

And other workloads are fine?

 

[krakah]

That would depend on the workaround . But no, probably not. This is a really basic function. It’s not like I can send out communication to everyone and anyone who would store data here that they can’t decompress a zip on a share stored on this device and then also put that level of trust in them that they won’t do it to the point I’m ok with chancing them bringing down the entire box just because they decompressed a zip.

My snark radar is going off but I’m going to just believe that was a genuine question.

 

[Ericloewe]

It is a genuine question. It could very well be that this is caused by some weird thing that clients generally ignore, in which case it should be fairly easy to narrow down and fix. If more workloads, particularly workloads that everyone else is doing without issues, are also failing, that would suggest some sort of configuration problem.

 

[krakah]

A reddit comment got me wanting to do some additional tests. Here are the results:

So interesting.... I installed FreeNAS in a VM on my hyperv server running on a DellR710 and setup the same exact scenario. The VM has 16GB of RAM, four cores of a Xeon 5677 which also runs 3.7ghz. Its about as similar as I can get to the hardware config as my other box I'm having problems with. It has 3x10GB disks in a pool with no cache. The major difference is that the underlying storage of the hyperv server is a local hardware RAID5 array on a percH700. With three 10GB virtual disks attached to the VM.

The network doesnt completely drop but the pings become really inconsistent overall:

https://imgur.com/a/Kz9Jpy9

Hard to tell if thats a problem or not... I am maxing out the 1Gb link while doing this. That may be normal. All boxes involved so far have been on the same switch.

Before and after doing the decompressions its all <1ms

https://imgur.com/a/wHBL9jb

CPU Usage on the VM got up to about 19%, but hovered mostly around 11-15%.

https://imgur.com/a/rGBuRIz

http://www.cpu-world.com/Compare/143/Intel_Core_i3_i3-4360_vs_Intel_Xeon_X5677.html

In the screenshot you can see a full 50MB/sec which is to be expected when writing/reading to the same share at the same time over gigabit.

The high CPU usage got me wondering what would happen if i reduced the VM down to a single core.

It struggles to stay above 30MB/sec, but also the network is only running at half capacity. I'd expect the pings to remain consistent. They're better, but not consistent. CPU usage while doing this was around 35-38%

https://imgur.com/a/hueID3Z

This got me thinking about hardware and/or possibly drivers built into the image. Like I said... I dont want to be THAT guy and be all "well this doesnt happen in windows".... but it doesnt. I really think the 3.7ghz i3 with 16GB/ram is more than adequate hardware for what I'm doing. The i3 has better overall performance than the Xeon

http://cpuboss.com/cpus/Intel-Xeon-X5677-vs-Intel-Core-i3-4360