From 8b9d2a6641632e21d3955e777cdd97c19b4663b9 Mon Sep 17 00:00:00 2001 From: weinzwang Date: Tue, 21 Sep 2021 07:55:58 +0000 Subject: [PATCH 1/2] Added a comment: Should be safe --- .../comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment diff --git a/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment new file mode 100644 index 0000000000..f192a37757 --- /dev/null +++ b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="weinzwang" + avatar="http://cdn.libravatar.org/avatar/e73d7d9e358f3b974d283fb0834cc5d9" + subject="Should be safe" + date="2021-09-21T07:55:57Z" + content=""" +I've been using git-annex with very similar setups for many years and never had any problems. I can't say anything about bare repos being more or less risky than non-bare ones, I've been using both on my server. Repos that can't see each other is a very common setup. +"""]] From 5a1387916e8142d3ec8387eeb98bd33ecc6e9d55 Mon Sep 17 00:00:00 2001 From: mih Date: Tue, 21 Sep 2021 09:22:19 +0000 Subject: [PATCH 2/2] --- ...ial_per-file_cost_for___96__add__96__.mdwn | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn diff --git a/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn b/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn new file mode 100644 index 0000000000..bb3dc89f72 --- /dev/null +++ b/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn @@ -0,0 +1,60 @@ +### Please describe the problem. + +Performance on Windows 10.0.19041 even on small text files is 10+ times slower than Git alone, and seems to have dropped over the past months of (windows, git, or git-annex developments). + + +### What steps will reproduce the problem? + +Compare performance of `git add` and `git commit` in a Git repo with vs without `git annex init`. + +The observations below have been taken from [this DataLad issue](https://github.com/datalad/datalad/issues/5994). The hardware of the test system is described over there, but only the relative performance is relevant here. + +- `git init`: 0.1s +- `git annex init`: 5.7s + +First timing info is the command executed in an annex-repo (after `git annex init`), the second timing is the same command executed in a plain Git repo. + +after creating a 3-byte text file: + +- `git add file`: 1.9s (0.1s) +- `git commit file -m msg`: 3.2s (0.1s) + +after creating two new 3-byte test files: + +- `git add .`: 4.5s (0.1s) +- `git commit -m msg`: 2.4s (0.1s) + +after creating eight more 3-byte text files: + +- `git add .`: 13.1s (0.1s) +- `git commit -m msg`: 1.6 (0.1s) + +now adding a 225 MB binary file + +- `git add binfiile`: 16s (13s) +- `git commit -m msg`: 2s (0.2s) + +no changes + +- `git commit --amend -m msg`: 2s (0.1s) + +So it looks as if there is a substantial per-file cost of `add` in an annex repo that is not explained by the underlying Git repo performance. + + + +### What version of git-annex are you using? On what operating system? + +- Windows 10.0.19041 +- Git 2.33.0.windows.2 +- git-annex 8.20210804-g1d3f59a9d + +### Please provide any additional information below. + +The linked datalad issue has more information on the configuration of the Git installation, but that only seems to affect performance broadly, and not git-annex specifically. + +I am reporting this behavior now, because it has worsened since [I last looked into performance on windows](https://github.com/datalad/datalad/issues/5317). It is unclear to me, which developments have led to this (also the windows version has progressed since then). However, even back then, it looked like there is a windows-specific performance issues that cannot be explained by the general handling of crippled filesystems or adjusted branches (comparing performance on an NTFS drive mounted on Debian vs a native windows box). + + +Thanks for git-annex! + +[[!tag projects/datalad]]