From e97ceaeaa62bd38fe8c0180cee801f0d129b689a Mon Sep 17 00:00:00 2001 From: midfield Date: Thu, 12 May 2016 02:55:56 +0000 Subject: [PATCH] --- doc/forum/performance_for_FTP_site_mirroring.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/performance_for_FTP_site_mirroring.mdwn b/doc/forum/performance_for_FTP_site_mirroring.mdwn index a76973a75f..552b2670e8 100644 --- a/doc/forum/performance_for_FTP_site_mirroring.mdwn +++ b/doc/forum/performance_for_FTP_site_mirroring.mdwn @@ -16,7 +16,7 @@ Here are my questions: 5. Another reason why I appear to be forced to use "unlocked" mode is that, as part of the mirroring, the directory permissions are set to match the site, which are not writable. git-annex appears to be unable to move the files that are inside of directories without write permissions. Note that I am the owner of the local files/directories, and lftp happily adds and modifies files insides of these unwritable directories just fine, presumably by temporarily changing the permissions. Is this correct? Should I submit a feature request here? -5. Although I am using WORM and unlocked mode, I found the initial "git add" and "git commit" of the 10K / 30GB of files to be pretty slow. It takes on the order of 30 minutes for the add and an hour for the commit. I didn't see a ton of either CPU or I/O activity. Is this to be expected? I would have hoped that the WORM backend prevents git from needing to actually read the files for a checksum. (I'm hopeful that with the WORM backend, subsequent add and commits will be a lot faster.) +5. Although I am using WORM and unlocked mode, I found the initial "git add" and "git commit" of the 10K / 30GB of files to be pretty slow. It takes on the order of 30 minutes for the add and an hour for the commit. I didn't see a ton of either CPU or I/O activity. A subsequent update of about 600 files is taking a long time to add (running 'git add -A'.) I assume commit time will also be long. Is this to be expected? I would have hoped that the WORM backend prevents git from needing to actually read the files for a checksum. 6. I understand that "thin = false" will lead to data duplication. I assume this will make the initial commits slower. Are there other performance implications of changing the thin setting?