mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2023-12-16 17:07:11 -04:00
commit e777ad9e87
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 31 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/forum/very_slow_on_exfat_drives/comment_15_1d7c3ff1eaeffe03fe7e3e25af822e4e._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="jkniiv"
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
subject="comment 15"
date="2023-12-12T19:25:16Z"
content="""
The fact of the matter is that HDDs have gotten shittier during the past decade or so because most of them
(except for sizes above 8TB and drives meant for the enterprise) already employ SMR (shingled magnetic recording)
instead of conventional recording techniques. It seems SMR is poison to all sorts of workloads having
small files and directories being rewritten (not that drives employing it have sequential speeds that are exactly
stellar either) like what git and git-annex are doing under the hood. I bought an 6TB WD Elements desktop drive recently
(knowingly an SMR unit because non-SMR HDDs are rather expensive here in Finland) as an git-annex archival drive and I was
flabbergasted at how slow it turned out for merely syncing git metadata. I'm on Windows and have to use adjusted-unlocked
branches so there's that but NTFS on Windows is not terribly slow -- maybe not as speedy as Linux filesystems but it caches
metadata rather well, so it's ok. The problem is that while my 4TB Seagate IronWolf non-SMR drive (git-annex) syncs
in a minute or two, my new 6TB takes a minimum of *ten* minutes or so to do that. At this point I have just resigned myself
to the fact that all my future archival drives where I use regular git remotes will be slow as molasses. I'd love to own
big, fast non-SMR enterprise drives but those will be outside my budget for years to come, I'm afraid. :/
"""]]

12
doc/tips/using_Backblaze_B2/comment_2_d7fd727cb38a0290de10f06539a23d27._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="aaa"
avatar="http://cdn.libravatar.org/avatar/df34e736d4a63a5c29e8bd513ed719ca"
subject="Key permissions"
date="2023-12-12T22:29:24Z"
content="""
I tried to use Backblaze B2 using the second method, and tried different application key permissions. Hopefully I can save your time if you’re going to use this special remote.
In order to init a B2 remote, you should create a key with the ability to read & write all buckets, and you must create a new bucket using git-annex (by setting a unique name in `bucket=`). If you create an empty bucket using Backblaze's web UI, then use that bucket for `git annex initremote`, you will receive this error message: `(InternalException (HandshakeFailed (Error_Protocol (\"expecting server hello, got alert : [(AlertLevel_Fatal,IllegalParameter)]\",True,HandshakeFailure))))`.
In order to enable a B2 remote, you need a key with read & write permission to the bucket you're using. If you created a key with only read permission, you can’t use `git annex get` on that remote.
"""]]