On 30Mar2015 11:29, Ranjan Maitra <maitra.mbox.igno...@inbox.com> 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 <c...@zip.com.au>
"What do you want to reinstall today?" - Bob O`Bob <o...@shell3.ba.best.com>
--
users mailing list
users@lists.fedoraproject.org
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
