On Mon, 25 Feb 2008 14:11:48 -0600 Terry <[EMAIL PROTECTED]> wrote:
> Are there any special considerations I
> should have in mind when moving this much data and more importantly,
> this many small files?
The short answer is "maybe". :) If you take a peek through the
(recent) list archives, you'
> A local transfer needs --no-whole-file if you want it to use the rsync
> algorithm (which uses more disk I/O, so it's not the default).
>
>..wayne..
Here are the stats on a small file...exactly as expected with everything
getting matched. Is this an issue with how much of the file rsync can loo
I ran rsync on the 59GB file again without preallocate on XFS. It created
only 383 extents...very low fragmentation.
Rob
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Hi All,
I just tried (on OS10.5.2) the new fileflags.diff patch
patch -p1 patch -p1 rej's )
then
./configure
make
then tried it out but it isn't copying the creation dates now
I noticed there's a new nightly build - if I patch against that, I
only see the first of the rejects:
amorton$
> A local transfer needs --no-whole-file if you want it to use the rsync
> algorithm (which uses more disk I/O, so it's not the default).
>
>..wayne..
I reran this test with the --no-whole-file option and received the exact
same results. Any idea on why some much data is being sent when the files
Hi All,
I just tried (on OS10.5.2) the new fileflags.diff patch
patch -p1 robert-dutoits-powerbook-g4-15:rsync-3.0.0pre10 astrid$ patch -p1
patching file compat.c
Hunk #1 succeeded at 45 (offset 1 line).
Hunk #2 succeeded at 63 (offset 1 line).
Hunk #3 FAILED at 137.
1 out of 3 hunks FAILED --
Rob Bosch wrote:
> The patch truncates the file with ftruncate if a transfer fails in
> receiver.c. This should avoid the problem you mention.
I was thinking of a user-abort (Control-C) or crash, but this is good.
> Even if this didn't
> occur, the file would exist on the FS with the predefined
The patch truncates the file with ftruncate if a transfer fails in
receiver.c. This should avoid the problem you mention. Even if this didn't
occur, the file would exist on the FS with the predefined size. It would be
in the allocation table and exist on the disk (you can see it under Windows
ex
Rob Bosch wrote:
> > Was that simply due to writing too-small block to NTFS? In other
> > words, would increasing the size of write() calls have fixed it
> > instead, without leaving allocated but unused disk space in the case
> > of a user-abort with --partial, --partial-dir or --inplace?
>
> It
> Was that simply due to writing too-small block to NTFS? In other
> words, would increasing the size of write() calls have fixed it
> instead, without leaving allocated but unused disk space in the case
> of a user-abort with --partial, --partial-dir or --inplace?
It could have been a function o
Hi,
We are seeing some RSync related issues (hangs, pauses, etc) in our
productions environment - we would like to seek profession services to
resolve the same at the earliest; The RSync version we are using is
2.6.4 and the constraint we have to work with is that we can't move to
latest version
Hello,
I have a large migration of a single system going from windows to
linux. We are moving 9 TB and 60 million files. I am planning on
using rsync to move this data. Are there any special considerations I
should have in mind when moving this much data and more importantly,
this many small fi
Rob Bosch wrote:
> > Though, did I get the right impression that NTFS generates lots of
> > extents for small writes even when nothing else is running?
>
> The fragmentation on NTFS was a problem even when nothing else was running
> on the server. The preallocation patch made all the difference o
> Though, did I get the right impression that NTFS generates lots of
> extents for small writes even when nothing else is running?
The fragmentation on NTFS was a problem even when nothing else was running
on the server. The preallocation patch made all the difference on NTFS and
cygwin. In that
Rob Bosch wrote:
> > Any idea why Glibc's posix_fallocate makes any difference?
> >
> > Doesn't it simply write a lot of zeros? In that case, why doesn't
> > rsync writing lots of data sequentially result in the same number of
> > extents?
>
> The destination server had a lot of other processes r
> A local transfer needs --no-whole-file if you want it to use the rsync
> algorithm (which uses more disk I/O, so it's not the default).
The transfers occurred across a local network but were on separate machines.
Rob
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinf
> Any idea why Glibc's posix_fallocate makes any difference?
>
> Doesn't it simply write a lot of zeros? In that case, why doesn't
> rsync writing lots of data sequentially result in the same number of
> extents?
The destination server had a lot of other processes running at the same
time. I sus
On Mon, Feb 25, 2008 at 08:48:22AM -0700, Rob Bosch wrote:
> The odd thing is that a huge amount of the file was resent again even
> though the files are identical at the source and destination.
A local transfer needs --no-whole-file if you want it to use the rsync
algorithm (which uses more disk
Rob Bosch wrote:
> Destination file on XFS
> - ftruncate, 59GB file, Execution time 52776 secs, 1235 extents
> - posix_fallocate, 59GB file, Execution time 53919 secs, 11 extents
Any idea why Glibc's posix_fallocate makes any difference?
Doesn't it simply write a lot of zeros? In th
>For a meaningful test, you should actually write 77GB of data into a new
>file and an ftruncated file and see if there's any difference in the
>resulting fragmentation.
>
>In your patch, you should use fallocate in place of ftruncate. If your
>glibc is like mine and doesn't provide direct access
Precisions:
If I run my patched rsync on 10.4 instead of 10.3, it's my function
that returns an error:
rsync: rsync_xal_set: lsetxattr("Src/60-bsd-flags/dir-with-
flags","com.apple.FinderInfo") failed: Unknown error: -5000 (-5000)
And error -5000 means:
afpAccessDenied
-5000
User does not hav
Wayne Davison wrote:
> On Sun, Feb 24, 2008 at 04:29:17PM +, Jamie Lokier wrote:
> > When compiled on a Linux system which doesn't have SYS_fallocate
> > (because it doesn't have a very recent kernel), but does have
> > posix_fallocate (because Glibc has had it for a while), I think that
> > pa
22 matches
Mail list logo
