Hello!
We are starting to deploy our file sync solution more widely and I am now
looking to verify that I am using the best mix of settings for performance and
reliability. We are using the automatic mode rather than the mirror mode,
because we are also using the backup (the sync, really) to provision new
machines that already have all the user's data pre-installed. As the user
makes changes on the current machine, the new machine is syncing those changes
down in real time so that when the new machine is delivered, it's completely
current - which is working really well!
We are backing up to a very large storage device in our data center which is
quite removed from us geographically, so I am looking to ensure that our
global settings are in fact optimized for performance and reliability. The
settings in our GlobalSettings.xml are:
<FreeFileSync XmlType="GLOBAL">
<Shared>
<Language>58</Language>
<CopyLockedFiles>true</CopyLockedFiles>
<CopyFilePermissions>false</CopyFilePermissions>
<TransactionalFileCopy>true</TransactionalFileCopy>
<LockDirectoriesDuringSync>true</LockDirectoriesDuringSync>
<VerifyCopiedFiles>false</VerifyCopiedFiles>
<RunWithBackgroundPriority>false</RunWithBackgroundPriority>
What if we turn off CopyLockedFiles? Will that simply skip a file that is
locked rather than try to use the Volume Shadow Copy feature and then copy the
file during the next pass if the file is now no longer locked?
I assume that TransactionalFileCopy is a smart move because it ensures
that the existing file is only removed once the new file has been fully
copied, so that makes sense to me in terms of reliability, and that this
is not really a performance issue.
Finally, what about LockDirectoriesDuringSync? Is this a key performance
feature or a reliability feature? What do you recommend we set this to for our
deployment?
Thanks again for some brilliant software!
Best settings for performance
- Posts: 74
- Joined: 17 Mar 2008
-
- Site Admin
- Posts: 7062
- Joined: 9 Dec 2007
Usually performance and reliability are at conflict and one needs to trade one
in favor of the other. FFS internally goes to great lengths to not give up on
any of the two and does so with success except for very extreme scenarios (in which case it favors reliability over performance). So
you generally needn't and probably shouldn't touch default settings.
>What if we turn off CopyLockedFiles
This is a reliability feature: If you are concernced you may copy files while
they are written by applications that do not support VSS (the usual suspects,
ms software like outlook *does* support it) you turn this option off. You'll
now get an error for each file that is locked and can take further action
(make sure the offending app is not running, or just ignore the error and try
again another time)
> TransactionalFileCopy
This is generally very cheap (perf) but adds one additional i/o access per
file, namely the renaming at the end. For unbuffered devices like USB memory
sticks there will be a slight perf drawback ; for buffered ones, like your
local HDDs, it is beyond measurement precision. But considering you get
garbage data should the copy process be terminated in what way ever (network
drop, power loss, system shutdown, what have you) without this option, it is
best left active. There are a few special scenarios (cloud sorages refusing
the .ffs_tmp extension) that require this to be turned off.
>LockDirectoriesDuringSync
It basically costs nothing (perf), and prevents all problems related to
multiple syncs running against the same source. The only reason this is
configurable at all is this special scenario:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3166021&group_id=234430&atid=1093083]
in favor of the other. FFS internally goes to great lengths to not give up on
any of the two and does so with success except for very extreme scenarios (in which case it favors reliability over performance). So
you generally needn't and probably shouldn't touch default settings.
>What if we turn off CopyLockedFiles
This is a reliability feature: If you are concernced you may copy files while
they are written by applications that do not support VSS (the usual suspects,
ms software like outlook *does* support it) you turn this option off. You'll
now get an error for each file that is locked and can take further action
(make sure the offending app is not running, or just ignore the error and try
again another time)
> TransactionalFileCopy
This is generally very cheap (perf) but adds one additional i/o access per
file, namely the renaming at the end. For unbuffered devices like USB memory
sticks there will be a slight perf drawback ; for buffered ones, like your
local HDDs, it is beyond measurement precision. But considering you get
garbage data should the copy process be terminated in what way ever (network
drop, power loss, system shutdown, what have you) without this option, it is
best left active. There are a few special scenarios (cloud sorages refusing
the .ffs_tmp extension) that require this to be turned off.
>LockDirectoriesDuringSync
It basically costs nothing (perf), and prevents all problems related to
multiple syncs running against the same source. The only reason this is
configurable at all is this special scenario:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3166021&group_id=234430&atid=1093083]
- Posts: 74
- Joined: 17 Mar 2008
Excellent, that is just what I am looking for - we may try running with the
CopyLockedFiles turned off only because we have people that are running Access
databases or VM images from the directories we are looking to back up, and
this might help us skip them - and we may also add in the size limit to
prevent copies of files over a certain size.
CopyLockedFiles turned off only because we have people that are running Access
databases or VM images from the directories we are looking to back up, and
this might help us skip them - and we may also add in the size limit to
prevent copies of files over a certain size.
