Seaf-gc sees problem, seaf-fsck does not

I have a weird situation with a repo on a seafile-pro instance:

sudo -u seafile seafile-server-latest/ 2888e691-7a4f-49da-b40c-cf6c1bf8c5ad

Starting seafserv-gc, please wait ...
[02/03/18 12:19:42] gc-core.c(783): Database is MySQL/Postgre/Oracle, use online GC.
[02/03/18 12:19:42] gc-core.c(807): Using up to 10 threads to run GC.
[02/03/18 12:19:42] gc-core.c(753): GC version 1 repo REPO(2888e691-7a4f-49da-b40c-cf6c1bf8c5ad)
[02/03/18 12:19:47] gc-core.c(517): GC started for repo 2888e691. Total block number is 29152.
[02/03/18 12:19:47] gc-core.c(75): GC index size is 14576 Byte for repo 2888e691.
[02/03/18 12:19:47] gc-core.c(276): Populating index for repo 2888e691.
[02/03/18 12:19:48] ../../common/commit-mgr.c(369): Failed to find commit 20f90decfa010308f839ab7b32d40139944243d8
[02/03/18 12:19:48] ../../common/commit-mgr.c(550): [comit-mgr] insert parent commit failed
[02/03/18 12:19:48] gc-core.c(302): Failed to populate index for repo 2888e691.

[02/03/18 12:19:48] gc-core.c(854): === GC is finished ===
[02/03/18 12:19:48] gc-core.c(858): The following repos are damaged. You can run seaf-fsck to fix them.
[02/03/18 12:19:48] gc-core.c(861): 2888e691-7a4f-49da-b40c-cf6c1bf8c5ad
seafserv-gc run done


However, seaf-fsck does not find / see anything wrong with the repository?

sudo -u seafile seafile-server-latest/ 2888e691-7a4f-49da-b40c-cf6c1bf8c5ad

Starting seaf-fsck, please wait ...

[02/03/18 12:22:34] fsck.c(595): Running fsck for repo 2888e691-7a4f-49da-b40c-cf6c1bf8c5ad.
[02/03/18 12:22:34] fsck.c(422): Checking file system integrity of repo REPO(2888e691)...
[02/03/18 12:25:43] fsck.c(659): Fsck finished for repo 2888e691.

seaf-fsck run done


It feels like seaf-fsck is not checking for things it should? Or seaf-gc is raising a false alarm?

I have a backup of all data, so that is not the issue, but is it possible to re-initialize the repo (as if there were no commits as of yet) so that I do not have to re-create download-links, sharing, etc.? Or do I really have to delete the repo, then re-upload the data and re-create all the sharing, access-rights, download links, etc?



Hi Martin,

Fsck only checks the current state for consistency. It seems some data in your history is corrupted. This corruption usually shouldn’t affect normal usage of the library. You may re-upload your data to a new library.

Thank you.
In that case, is there a way to delete references to the offending commit from the database so that the repo regains garbage collection capabilities?

I encountred this issue more than a year ago and i am still unable to run gc on my library to remove old history because of this, size is becomimg a problem. New repo and moving there is not an option, since i need to keep at least 2 years of history.

Since this is a big problem for me, i too would at least like a manual workaround. I suposse manual workaround would only involve deleting the offending commits? But i am lost in seafile folder hierarchy, if someone can at least provide a way to find them…

The manual workaround is to copy all data to a new library (history won’t be copied) and fully delete the old library.

1 Like

Thanks, but copying to a new repo is the same as desaster recovery from a full backup,
In other words there is no workaround. That is what I will end up doing, I suppose. It is still very disappointing having to re-create all the sharing links, etc. and I am not talking about just a couple of links either, but rather a couple of dozen links.
Anyway, thanks to all for your input and suggestions!

Yes, hardware failures are disappointing.