Problem: Copying files from Isilon to same Isilon = Slow (Using CIFS share and Windows machines.)

furthermore it could be worth a try to upgrade to Server 2016 and use OneFS 8x. Then enable Server side copies which will cause the copy to be server-internal.

Most likely you will see best improvements by doing multiple copies in parallel.

Tools like emcopy and robocopy have capabilities for this built in, have you tried them yet?

I would not recommend to allow users log in to the Isilon cluster directly.

If you have Isilon SyncIQ licensed it can also be levereged for intra-share

parallel and efficient copies. Just note that an admin person needs to be involved

for manual copies; or some regular schedule needs to be set up for automation.

Using NFS just to manage data with Windows ACLs is probably not

work the hassle...

hth

-- Peter

SyncIQ will copy the files the fastest, but it will be a Read Only copy until you delete the SyncIQ policy and make the directory Read Write.

"Server side copies", interesting! Thank you so much for this! I'm going to research it!

Peter,

Multithreading: Yes, Robocopy is our go-to copy tool and most of us manually set multi-threading to 8.

SSH: To compensate for "SSH is not recommended" we were thinking about making a Windows application that handles the SSH session and copy commands, while at the same time hides the username and password. In other words the application would present the end user with a GUI that requests SOURCE and DESTINATION. Said application would have the SSH credentials built into it. Would something like this make a person in your position feel more comfortable?

Please keep in mind we are very attracted to the possibility of copying files locally on the Isilon. As a bonus, we are trying to find out if said copies would be symbolic links. As in they are not actually copies, just pointers to the original files.

NFS: When you mentioned NFS might not be worth the hassle. If it copies files 2x faster it would be worth it in my opinion. Again we might be able to make a GUI that handles the copy work. Nonetheless the sources below make me think the hassle wouldn't be that large. But my understanding of the Isilon and Linux are limited.

“Users who gain access to the cluster over SMB can access UNIX files stored over NFS with their LDAP accounts. Likewise, users who gain access to the cluster over NFS can access Windows files with their Active Directory accounts.”
Source https://www.emc.com/collateral/white-papers/h12417-identities-access-tokens-isilon-onefs-user-mapping-service-wp.pdf

“OneFS uses identity mapping to translate between Windows and UNIX permissions as needed.”
Source http://doc.isilon.com/onefs/7.0.1/help/en-us/GUID-5A903ADA-A3CA-4DC4-B314-586583B0ACF0.html

Hm... haven't heard "It depends" for some time now in this forum

You earlier mentioned "millions of files", so these presumably are small files, like couple tens of KBs?

With small files, most time is spent creating the new files,

rather than transfering data from source to new files.

Both network/protocol latency and file system "metadata" write operation contribute,

and getting rid of network/protocol buys you only one part of the job, maybe even

the smaller part compared to the network protocol. In depends... on physical

network latencies, protocol efficiencies (SMB2, SMB3 with server-side copies, NFS)

as well as metadata write efficiencies on file system level (metedata r/w acceleration on SSD,

metadata write caching/coalescing).

This is why most of the improvements I'd expect from doing operations in parallel.

It would take some efforts to build not only a safe "ssh wrapper" but also

a reliable parallel copy tool to run locally.

But it seem you are willing to spend some energy on the problem, so

why not first establish some baselines

- robocopy with higher thread counts (a google for other tools promising highly parallel copies)

- ... same with multiple instances on different directories!

- ... same with server-side copies enabled

- plain local copies with cp or cpio, also consider cp -c (cloning, an Isilon extension)

- (NFS -- nah, beware of the permissions/ACL complexity)

- SyncIQ (Yes! get a trial license from your account team)

Of course, carefully watch overall cluster performance when

stretching the test to highest levels(!)  Getting the millions

of files copied fast enough, at the expense of general

performance sufferings, looks like a less welcome suprise.

Let us know what you find, for your specific setup.

-- Peter

Would Server-Side Copying work with Windows 10? I'm assuming so because it uses the same version of SMB 3.1.1?

yes.

Windows 8 and later

And to correct myself it would also work with Server 2012 and with Server 2008 (but here only via robocopy).

Question: Within OneFS 8x, can 'Server-Side Copy' be enabled per CIFS share or is it an all or nothing setting?

checked on 8.0.0.x and it seems like it's all or nothing. afaik Continious Availability and ServerSideCopy are exclusive. since CA is configurable per share you could enable CA on a share you don't want SSC work with and enable SSC globally.but then you enabled CA on the Shares you didn't want to touch for SSC - so you didn't win a lot

yeah, it's only in the  global SMB settings, like a couple of other SMB features...

Is SSC on by default? Or does one have to manually toggle it on within OneFS 8x?