/src has 1.5 TB of data, /dest/ is a new destination and started out empy. Oh ya, both /srv and /dest are cifs shares. I know that /src is off a Windows 2008 server and /dest I have no idea. The /src is a local file server connected via 1g ethernet and /dest is remote on the other end of a slow WAN link.
Here's the mount output:
//remotesf/dest on /dest type cifs (rw,mand)
//localfs/src on /src type cifs (rw,mand)
Here's the part that's got me scratching my head. This transfer has been running for a few hours and seems to be fine. I know it's gonna take a few days and I'm good with that. BUT, I'm watching transfer and as a file completes I'm doing a ls -lah so I can see the completed file but its not there... like all the directories are being created, the copies are taking time and doing their work but when I browse or ls the directory it's empty.
What's the deal?
---------- Post updated at 10:20 PM ---------- Previous update was at 10:18 PM ----------
Bonus question; without stopping the running job anyone got a good way to see how much has transferred? df -h /dest doesn't seem to produce any useful output.
DustinT, I don't have any experience with cifs and I don't have any answers to your questions. But I do know what I would do if I were in your situation. I am rather conserative by nature and I don't simply go jump into some unkown pond. I dip my toe in the water first...
I would abort this job since you only have a few hours invested in it. Set up a very small sample .. a few dozen files in a few dozen subdirectories. It should be large enough to consume about 5 to 10 minutes. Rsync that. During the rsync do you see the files appear? When it's done does everything look ok?
If your sample works ok, then start the real job. If the sample doesn't work, the real job probably won't work either. Figure out how to get the sample working. And then do the big job.
If you let the multi-day job continue to run you risk having nothing to show for all those days. Maybe that's not a problem. If you have several weeks to do this and it's just a background sort of thing maybe you can let it roll and see what happens. But even in that case, I would have tried a small sample first. Just saying....
On an older system, we set up cifs that required authentication: the controlling (parent) process had to be an already authenticated user to a Windows fileserver before any file activity was allowed. Authentication was persistent for the duration of the cifs mount.
Any unauthenticated process that ran in the background simply hung, root included.
You make some excellent points in your post. I have done some testing of the process, spent a couple hours on it as a matter of fact. Testing from the /src and too a remote linux server as the dest over ssh worked perfectly. For the production work, the /dest was switched to a remote cifs server which I didn't think I needed to test for. Now, it seems obvious that config needed testing too.
Both the /src and /dest were mounted with domain credentials. Wouldn't that cover the authentication needs of the rsync process transparently?
On another note, it's interesting because while the file is being copied, I can see it if I browse the remote directory. Once the transfer is completed, the remote version disappears.
Turns out that error was because I wasn't running rsync with enough permissions. That was an easy fix but I needed one more thing to complete this project.
I ended up having the user onsite at the remote location send the files on a USB drive and then I used rysnc to complete the transfer once the drive was here. It proceeded much more quickly and wrapped up after about 48 hours. The remote user sent more files than I was initially targeting so the final transfer ended up being 2.6 million files.