On 30Mar2015 11:29, Ranjan Maitra <maitra.mbox.ignored@xxxxxxxxx> wrote:
I am at my wits end with this, so I thought I would post here to see if anyone had any thoughts. The only connection with F21 (updated in all installed components) is that everything is on a F21 machine. So, I have a cifs share mounted onto /mnt/space using the usual mount.cifs option with sec=ntlmv2. I wanted to copy the following directory (kmeans) onto /mnt/space -- because I wanted to preserve permissions and structure, I tried rsync: rsync -avSz --delete --progress kmeans/. /mnt/space/kmnsinit So here is the problem: The original directory has size: % du -sh kmeans 156G kmeans But the copying has continued on and on with no sign of ending (and we are at 378GB). % du -sh kmnsinit 378G kmnsinit
If you are using a CIFS share, does that mean the far end is not a UNIX filesystem? The -S (sparse) option is only useful if the backend can store sparse files, otherwise the backend will just store lots of blocks of zeroes (presuming you really have sparse files).
Is the source kmeans directory full of hard links (not symlinks)? If so, rsync will not preserve hard links without the -H option (even with -a) and regardless I do not know if CIFS supports making hard links or if your backend supports hard links).
I also tried without the . after the kmeans/ in the rsync command (though not sure why it would matter) but to no avail.
With rsync, a trailing / is sufficient. A trailing . can have subtle effects on naming (top level versus one level down) but should not affect the main problem unless this is your second run at things, differently invoked (if so, check that you don't have an extra "kmeans" subdirectory at the far end, resulting in two copies, one at the top and one one level down).
(Same story, and note that it is not ending at 378G but going on, and chances are will go on for some more.)
Add the --progress option. It will give you a better idea of how far through the file list rsync has got.
Is it possible that since all things Windoze are bad, the cifs puts stuff all over the place and represents large files differently. Is it possible to however make it behave?
If the far end is windows, certainly sparse files will no longer be sparse at the far end. This kind of thing is one reason we get so picky when getting employers to order NASes; we asked for a QNAP (cheap, useful, Linux backend) and they wanted to order Microsoft's storage thingummy, which would have broken all sorts of stuff just like what you're encountering.
Does anyone have an explanation and solution for the above? I apologize again for the largely OT nature of this post.
Seems on topic to me. Does anything above assist? Cheers, Cameron Simpson <cs@xxxxxxxxxx> "What do you want to reinstall today?" - Bob O`Bob <obob@xxxxxxxxxxxxxxxxxx> -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
