we have a problem with one LUN on our FAS2050. This LUN is connected via iSCSI.
The content of the LUN are millions of windows files on NTFS. (720 GB - 87 % used). We have migrated these files via robocopy in the past from a EMC CX300.
But now we have a problem with the read performance. If we write a test file with 2,5 GB to the LUN, the file is written in a few seconds to the LUN.
But if we copy (read) this file to a local Disk, the process takes up to 10 minutes. So we have a big problem with our backup time.
If we create a new LUN and connect this LUN to the same server via iSCSI and copy the file from the new LUN to a local Disk, the process takes up a few seconds.
So I think we have a problem with the specific LUN. Have you any ideas to solve our problem.
Thank you for your help,
Hi Oliver (and welcome to the forums! )
All symptoms in my opinion lead to one suspect - fragmentation.
Have a look at this threads for fairly thorough description what may be going on in your environment and what you can do to improve things:
(or just type 'fragmentation' in the search field)
You stated that you have millions of files on the first LUNs. That seems to be the problem to me. What backup methology are you referring to?
You mention you have created a new LUN and it performs better but from what I can read the first LUN also does 2.5GB in seconds. Also
from what I can read the new LUN does not contain millions of files, is this correct?
My theory is that if your server does not handle millions of small files as fast as 1 big file. This is logical.
I suggest you try the following. create a new LUN again, map it to the server. copy one big file, note the speed.
Now use the "makefile" command on the netapp to create a few million small files
99A*> priv set diag99A*> mkfileusage: mkfile size filename [filecount [stepsizeinblocks]]
For example: mkfile 4kb /vol/volume/qtree/LUN 1000000 > this will create 1 million small files in your LUN
and then try to copy this, compare with the previous copy. You will see that it will take a lot longer to copy many small files than 1 big file.
partially because each inode needs to be processed, each file need to be searched for and found etc.
In short, what I am saying is that what you see could be normal.
Could you collect perfstat while copying the 2.5-GB file to local disk? I think that will help understand the issue.
Live Chat, Watch Parties, and More!
Engage digitally throughout the sales process, from product discovery to conﬁguration, and handle all your post-purchase needs.