Faulty git+ssh repository on encrypted USB drive

[Gilead]

TL;DR; erratic behavior of B3 git+ssh repositories on USB drive with LVM drive encryption, don't know how to solve. Git reports various errors on basic repo commands after creation. Tried with two different and supposedly good USB drives.

What I am trying to achieve: I am using the B3 as a home server on the LAN, and I am trying to set up various GIT repositories on the server for local sharing of various types of files. Because these contain personal information, and in order to easily move it to another server if needed, I want the repos to be on an encrypted external drive.

The problem: erratic behavior of the git repository on the B3. Initial repository creation seems to work just fine, but when I later try to access the repositories remotely, or run integrity check on the repositories, there will be seemingly random git errors - which some times occur, some times not. Needless to say, I do not want to keep my most important files on an unstable setup which I do not trust.

I am very familiar with all the various technologies involved. SSH access to the B3 from the LAN works just fine. I have usede git on various systems before without problems, and I have used git for cloning repos onto the B3 before without any hiccups - which I believe was done on the main drive using encfs for data protection. I have used drive encryption on various drives on other servers before without any problems, and I have set up the USB drive on the B3 from the B3 itself, using "cryptsetup luksFormat" etc. The drive mounts just fine, and there seems to be no errors reported for the file system itself.

My first suspect was the USB drive, so I replaced it with another - same problem persists just as before. So I thought before I spend additional days researching the problem, I'd go on the forum and see if others have suggestions. I'm getting too old and time is too short for using several evenings researching this type of problem, so right now the alternative solution is essentially to ditch the B3 and buy something else.

On the B3 side, when I run "git fsck" on repositories, I will typically get errors like this:

error: ./objects/pack/pack-c0388647c0004d0f3556a8a4b800b02a341b485b.pack SHA1 checksum mismatch error: index CRC mismatch for object 904f1410ca75fef191509e13b2d8bd4d84a851ea from ./objects/pack/pack-c0388647c0004d0f3556a8a4b800b02a341b485b.pack at offset 793 error: index CRC mismatch for object d2074a7ef1e449d4b175485f543eada52980226c from ./objects/pack/pack-c0388647c0004d0f3556a8a4b800b02a341b485b.pack at offset 349731 error: index CRC mismatch for object 4a53775671767e43751bc07ce4aaefedcf01a1d4 from ./objects/pack/pack-c0388647c0004d0f3556a8a4b800b02a341b485b.pack at offset 1746036

On the remote client side, an operation like "git push origin master" will typically give errors like this:

error: non-monotonic index ./objects/pack/pack-ad47dd7de7f21bdb0d8084f8ad366c48ddb869bb.idx error: refs/heads/master does not point to a valid object! Counting objects: 442, done. Delta compression using up to 8 threads. Compressing objects: 100% (413/413), done. error: failed to read object 0d100289d980c87826a60f4ebeb8ddbae70bf73a at offset 44090 from ./objects/pack/pack-ad47dd7de7f21bdb0d8084f8ad366c48ddb869bb.pack fatal: object 0d100289d980c87826a60f4ebeb8ddbae70bf73a is corrupted error: pack-objects died of signal 13

Client side is Ubuntu 12.04 running git version 1.7.9.5, and the B3 is running 1.7.2.5.

And just to repeat - I have done identical setup several times on other systems without a hitch, following exactly the same procedures. So I am assuming and hoping this is not a user problem.

Any thoughts or suggestions?

[Gilead]

Thought I'd make an update to my previous post; it seems the problem is likely related to full drive encryption. I tried an alternative setup with encfs based encryption, and so far there seems to have been no problems. The change from the previous setup was to format the USB drive as a regular EXT4, to set up an encrypted folder with encfs using the "--public" option, and place the secure content there. Though not my preferred setup, it is an acceptable workaround.

Drive access is unfortunately rather slow which does not seem to be CPU related (the B3 runs at only around 25-30% CPU for ssh and encfs combined), and I'm only getting about 1MB/s data transfer (including wired LAN access). The USB device reports USB 2.0 speed so I would have expected better performance. But I can live with it.

Though I have a somewhat acceptable workaround, I'm still interested in hearing about experience with similar problems with full drive encryption, and/or USB drive speed problems.