Please describe the problem.
When doing
git checkout 3b18836
on a very large repository, where tens of thousands of files will be changed, I get many
error: external filter 'git-annex filter-process' failed error: git-annex filter-process died of signal 15
and finally
git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) fatal: the remote end hung up unexpectedly
What steps will reproduce the problem?
git checkout on a really big commit.
What version of git-annex are you using? On what operating system?
The system and all the SW should be up to date.
% git --version
git version 2.34.1
% git annex version
git-annex version: 10.20220322-1~ndall+1
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 9
% uname -a
Linux 5.15.0-33-generic #34-Ubuntu SMP Wed May 18 13:34:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
% cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
The computer has 128GB of main memory, and so is not running out of that.
This is a large repository:
du -sh . p 43G .
(62)% du -sh .git
42G .git
(63)% du -sh .git/annex
19G .git/annex
% git gc
Enumerating objects: 375565, done.
Counting objects: 100% (375565/375565), done.
Delta compression using up to 12 threads
Compressing objects: 100% (153675/153675), done.
Writing objects: 100% (375565/375565), done.
Total 375565 (delta 215701), reused 364628 (delta 207259), pack-reused 0
73.38s real 97.69s user 4.93s system 139% 0,0 socket 13753 mem git gc
I'm trying to recover from a mess caused by creating a new remote repository, making it shallow to save space, and updating it by mounting it on a local system with sshfs, etc. That caused an unintended rebase messing things up, e.g., git log shows most of the commits vanished (merged?). So I was trying to go back to an earlier, good, commit. However that requires changing, basically, everything. And that seems to be too big a change for git annex to process.
FWIW, I'm not using lfs.
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Otherwise, it's great.
How big a commit are we talking here, in terms of number of files added/changed?
I've tried with 10000 modified files and not seen a problem IIRC.
Also, signal 15 is SIGTERM, which would be a strange signal to happen unless it were ctrl-c'd.
Final weird thing is "fatal: the remote end hung up unexpectedly", since that would indicate a git fetch was running, and git-annex certianly does not fetch..
I also saw this when adding a single file to git:
But, I have not succeeded to reproduce that again. This was in a v9 repository BTW.
Feeling like this is most likley a pkt-line protocol bug in git-annex, and probably one inovlving empty files. Both because of the prior comment with the empty file and it turns out there is also an empty file in my first reproducer.
Here is a
GIT_TRACE_PACKET=1
log when reproducing it. I have omitted the actual content of my files..Now, from git's perspective, the last response of "0000" does look wrong. It should have been "status=success" followed by "0000" and then the file content, and then "0000" and "0000" again.
But as seen in the strace, git-annex sends more than that.
My guess is that git-annex is sending one 0000 too many for an empty file.