According to the Guidelines:
1) TeraStation III Rack 8.0TB NAS (TS-RXL)
2) Firmware 1.30 (latest I guess)
3) 35 Windows XP-Client Users on Windows 2003 SBS domain with ADS, Full-Gbit-Switch, the NAS is in trunk mode but no Jumbo frames
4) On this NAS project data is stored only. To have easier access users work directly in the respective folders in the network share.
Since we copied the shares from DC (to reduce storage, because of future virtualization) to the NAS, the access to the shares seems to be limited in concurrent connections.
We work with SoundPlan 6.x and 7.0 a typical project folder created by this program contains approx. 150-200 files (but only 40-80MB) and on some program commands SoundPlan needs to open at least 100 files to create work data. The most of these opened files are just few 10 to 500 KB.
As long as the shares were hosted on the Windows 2003 SBS no problems occured (and the server has only one Gbit NIC online!). Since we copied the shares to the NAS, Soundplan hangs on these operations for minutes and sometimes it completely crashes.
When I copy the project folder local on a work station, it runs as quick as before using the NAS.
So I guess that there is an open file limit on the Terastation, and if so, how to turn off or change?
We're only 35 Users. I hope there is a solution!
TIA Mike
Is this limitation a lack of Firmware?
The TSIII supports 48646 open files, so your qty of users isn't the issue.
Our recommendation is to first simplify and get the environment and unit stable.
turn off Port Trunking and use the first LAN port (not the second) as your primary interface.
Oh wow 48646! (How/Where to find out this number?)
The Port Trunking was meant to raise the Bandwith and a kind of fail over.
Next Maintenance is on this weekend, so I'll try using only the 1st NIC.
"Raid is no backup" - I know so the NAS is backed up to another one (2nd TS3) and copys on ext. hard disks.
We got the number from Engineering.
Stripping down to port number one is just for troubleshooting, it's not meant to be a fix.
We haven't tested on the appliication you're using and that app could be a factor.
It's me again!
Maintenance is over, but no improvement has perceived.
So I tried to get some Information via Sysinternals Process Monitor and I got:
08:58:36,6507059 SPDoc.exe 3576 CreateFile I:\Zwischenablage\EDV\_testmaik\S6100.1\Project.sp SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened08:58:36,6567268 SPDoc.exe 3576 LockFile I:\ZWISCHENABLAGE\EDV\_TESTMAIK\S6100.1\Project.sp FAST IO DISALLOWED Exclusive: False, Offset: 0, Length: 4.294.967.295, Fail Immediately: False
I searched google for FAST IO DISALLOWED and found:
Fast IO = A means of reading or writing a cached file without going through the work of generating I/O request packet (IRP).
I think this is the problem, because with fast io disallowed much more overhead is generated. So is there a way to work around this limitation?