Server CE 7.1.4 - fsck does not fix anything about a "failed to open block for read: No such file or directory" error

Seafile Server
1

Hi

My Seafile clients can’t sync on a specific library and tell that there is an “Server Error”.
There is in the server’s seafile.log file this line:
[08/26/2020 04:51:04 PM] ../common/block-backend-fs.c(237): [block bend] Failed to stat block 6adb0458-c591-4637-bce8-7eae86cfa483:7ded429f4357231c1c482e7783958054510dd232 at /opt/seafile/installed/seafile-data/storage/blocks/6adb0458-c591-4637-bce8-7eae86cfa483/7d/ed429f4357231c1c482e7783958054510dd32: Aucun fichier ou dossier de ce type.

“Aucun fichier ou dossier de ce type” meaning; No such file or directory.
“6adb0458-c591-4637-bce8-7eae86cfa483” being the library id
“7ded429f4357231c1c482e7783958054510dd232” being the block
And indeed there is no “ed429f4357231c1c482e7783958054510dd232” file in the 7d subdirectory of the library.

What I did:
-I stopped the only client that have ReadWrite access to this library
-I ran a Seafile fsck with dry-run (i.e. without the -r flag) on the library, and got:

seafile@xxxxxx:~/installed/seafile-server-latest$ ./seaf-fsck.sh '6adb0458-c591-4637-bce8-7eae86cfa483'

Starting seaf-fsck, please wait ...

[08/26/20 11:20:03] fsck.c(590): Running fsck for repo 6adb0458-c591-4637-bce8-7eae86cfa483.
[08/26/20 11:20:03] fsck.c(416): Checking file system integrity of repo backup_xxxx(6adb0458)...
[08/26/20 11:24:16] fsck.c(95): Repo[6adb0458] block 6adb0458-c591-4637-bce8-7eae86cfa483:7ded429f4357231c1c482e7783958054510dd232 is missing.
[08/26/20 11:24:16] ../../common/block-backend-fs.c(70): [block bend] failed to open block 7ded429f4357231c1c482e7783958054510dd232 for read: No such file or directory
[08/26/20 11:24:16] ../../common/block-mgr.c(235): Failed to open block 6adb0458-c591-4637-bce8-7eae86cfa483:7ded429f.
[08/26/20 11:24:16] fsck.c(654): Fsck finished for repo 6adb0458.

seaf-fsck run done

-I then ran the fsck with the repair flag, got this:

seafile@xxxxxx:~/installed/seafile-server-latest$ ./seaf-fsck.sh  --repair '6adb0458-c591-4637-bce8-7eae86cfa483'

Starting seaf-fsck, please wait ...

[08/26/20 12:04:25] fsck.c(590): Running fsck for repo 6adb0458-c591-4637-bce8-7eae86cfa483.
[08/26/20 12:04:25] fsck.c(416): Checking file system integrity of repo backup_xxxxx(6adb0458)...
[08/26/20 12:08:33] fsck.c(95): Repo[6adb0458] block 6adb0458-c591-4637-bce8-7eae86cfa483:7ded429f4357231c1c482e7783958054510dd232 is missing.
[08/26/20 12:08:33] ../../common/block-backend-fs.c(70): [block bend] failed to open block 7ded429f4357231c1c482e7783958054510dd232 for read: No such file or directory
[08/26/20 12:08:33] ../../common/block-mgr.c(235): Failed to open block 6adb0458-c591-4637-bce8-7eae86cfa483:7ded429f.
[08/26/20 12:08:33] fsck.c(654): Fsck finished for repo 6adb0458.

seaf-fsck run done

Done.

But that didn’t change the result: Server Error

-I then stopped Seafile and ran a GC, and then re-did the fsk, but to no avail.

Do someone have an idea about my problem ?

PS:

  • OS: Linux Debian 4.19.98-1 (2020-01-26) x86_64
  • libc6:amd64 2.28-10, Python 3.7.3
  • Seafile Server 7.1.4, with MySQL 5.6.30-1
  • the thing that surprised me is that the fsck command didn’t seem to behave differently with the –repair flag: there is no message, no warning, no clue about the operation; it really make me suspicious about the real activation of the repair mode
1 Like
2

I do not have a real solution here but this is how I got my clients to sync again:

Fsck the library: /opt/seafile/seafile-server-latest/seaf-fsck.sh -r <lib_id>

Note the missing block hash. Run this script in seafile-data/storage/blocks/<lib_id>:

function handle() {
	touch $1
	chmod 0600 $1
	chown seafile:seafile $1
}

handle ./<first_2_chars_of_first_block_hash>/<rest_of_first_block_hash>

Run /opt/seafile/seafile-server-latest/seaf-fsck.sh -r <lib_id> and add other missing blocks that come up. Rinse and repeat:

handle ./<first_2_chars_of_first_block_hash>/<rest_of_first_block_hash>
handle ./<first_2_chars_of_another_block_hash>/<rest_of_another_block_hash>
# ... and so on

It’s annoying and it’s tedious, but it will work eventually, albeit not without data loss from the missing blocks.

Note on how this works: seaf-fsck apparently only repairs a lib when blocks are broken, not when they are missing. So we just add empty blocks (=broken) and have seaf-fsck remove them one by one.

1 Like
3

This is a known bug and will be fixed in the next version.

1 Like
4

Is the bug fixed with Seafile 7.1.5?
I am using Seafile 7.1.5 CE and have exactly the same problem

1 Like
5

This is fixed in 8.0 version.

1 Like