My client freezes at downloading a library at 3%, when i checked for corrupted data via fsck i found out a block is not readable. The block has the same permissions as the others.
However when trying to fix it by calling fsck with --repair flag, it doesn’t do anything:
root@lemaker:/home/bananapi/seafile/seafile-server-6.2.2# ./seaf-fsck.sh --repair 3456fd58-3ecb-4b44-b31b-90075e6369a9
[08/18/18 09:12:54] fsck.c(586): Running fsck for repo 3456fd58-3ecb-4b44-b31b-90075e6369a9.
[08/18/18 09:12:54] fsck.c(413): Checking file system integrity of repo Media(3456fd58)...
[08/18/18 13:33:02] ../../common/block-mgr.c(241): Failed to read block 3456fd58-3ecb-4b44-b31b-90075e6369a9:5c9ccd78.
[08/18/18 13:33:02] fsck.c(650): Fsck finished for repo 3456fd58.
After that, nothing changes. Client still frozen after restart, block still corrupted when checking with fsck. How can i fix this? I would even not mind deleting the file where the block is corrupted but checking the repo with the id 3456fd58-3ecb-4b44-b31b-90075e6369a9 i don’t find any folders with the name 5c9ccd78.
Have you check the file permissions?
Also I strongly recommend against using a bananapi. Did the self in the past and it is very unreliable hardware.
Hello @shoeper ,
thanks for the reply. I don’t think it’s the file permissions as i never changed something manually- But tell me how to check it when i don’t find the right block folder?
I use the bananapi now for 4+ years and never had a hardware problem.
Rather go for a small NUC, they are faster, have more resources and don’t even need a lot energy.
It might still make sense though to rent a cloud instance.
@DerDanilo @shoeper Sorry, but this was not the question. Yes, maybe I will think about other hardware/cloud in the future, but right now i just want to get this problem solved.
Can anyone give me a hint on how to fix this block? It would even be okay to just delete the file where the block is corrupted, so my seafile client can sync the rest.
Okay, best solution is to create a new library and move the files there folder by folder.
For what it’s worth I saw a similar issue recently on a Seafile CE 6 that I think was related to hardware (failing).
I detected a collection of unreadable blocks while doing a routine backup via rsync. Interestingly I was able to grab an image of the disk successfully using a Live CD.
I checked the partitions (again, using Live CD boot) and reset permissions. All appeared fine although but when back in system boot (Ubuntu 16.04) Seafile fsck still failed and rsync still showed errors due to the unreadable blocks.
I replaced the hard drive (simply out of desperation) all to no avail. The problems persisted. Finally I swapped the drive to a new CPU (quad core i7 in my case) and everything worked again. I did have to clean up some 0k bad blacks, however, but the system has been working since.
I don’t feel I have a good understanding of what went wrong, or what precisely was the underlying cause of the bad blocks, but I want to throw it out to you in case it helps.