Repeated git repository corruption, but BTRFS apparently okay

Hello.

I did not see an english language software topic, so… posting in “General discussion”.

Again I had this on my Omnia router:

/etc> git fsck                                                 
error: object file .git/objects/d9/8cb4b8149259d7214515a42a3f7acc15aef489 is empty
error: object file .git/objects/d9/8cb4b8149259d7214515a42a3f7acc15aef489 is empty
fatal: loose object d98cb4b8149259d7214515a42a3f7acc15aef489 (stored in .git/objects/d9/8cb4b8149259d7214515a42a3f7acc15aef489) is corrupt

Yet:

/etc> btrfs scrub status /
scrub status for […]
        scrub started at Tue Feb  6 23:19:58 2018 and finished after 00:00:05
        total bytes scrubbed: 234.79MiB with 0 errors

I was able to restore from a rsync backup from January. The backup from February already was corrupted.

This is the second time this is happening. Any advice on what is going on there?

Sorry, I now see that there is an english language software category. Please feel free to move the thread over to it.

I was able to restore a slightly newer copy from snapshot:

   45 | post      | 2018-01-22 17:41:30 +0100 | Automatic post-update snapshot
   46 | pre       | 2018-01-30 20:38:02 +0100 | Automatic pre-update snapshot

45 is still good, 46 is broke.

Hello,
can you tell us how the file get there? Are you using git pull for that file or something else?

You have some repository in folder /etc? In snapshot, where it doesn’t work can you please try move that file? Something should be in kernel messages.

Btrfs scrub just verify block checksums, you should use btrfs check, but for that you’ll need first to update NOR and this thing will happen in Turris OS 4.0.

Other recommendation is to use for git and also for lxc containers external device like usb sticks, usb hard drive and so on.

Hi Pepe.

I just did “git init” in /etc in order to manage configuration files of Omnia Turris in git and be able to clone them to my laptop. The file got there by some commit in /etc. But it does not appear to be completely written. The file is just empty. What is NOR? It is really just a little repo for TurrisOS config files, so external storage or LXC containers do not apply there.

~> schnapps mount 46
Snapshot 46 mounted in /mnt/snapshot-@46
~> cd /mnt/snapshot-@46/etc

/mnt/snapshot-@46/etc> git fsck
error: object file .git/objects/38/c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad is empty
error: object file .git/objects/38/c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad is empty
fatal: loose object 38c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad (stored in .git/objects/38/c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad) is corrupt
/mnt/snapshot-@46/etc#128> ls -l .git/objects/38/c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad
-r--r--r--    1 root     root             0 Jan 22 17:43 .git/objects/38/c7b2a3b8f8f64f5f8c1ee2f928bec81e9533ad

This somehow reminds me of the delayed allocation issue with Ext4 + XFS, but I do not remember having a sudden power loss directly after committing to that directory.

There is nothing about above accesses in dmesg.

Thanks

I did not see this type of corruption so far anymore.