Thanks for the reply. (I sent you first reply accidentally only to you.)
On Wednesday, 23 March 2022 at 15:35:59 UTC+1 [email protected] wrote:
> Hello,
>
> [...]
> Checking lost+found...
> [...]
>
>
> Checking contents (names)...
> WARNING: Content entry for inode 3 refers to non-existing name with id 1,
> moving to /lost+found/-3
>
> [...]
> > ERROR: Uncaught top-level exception:
> [...]
>
>
> File "/usr/lib/python3.10/site-packages/s3ql/common.py", line 117, in
> inode_for_path
> inode = conn.get_val("SELECT inode FROM contents_v WHERE name=? AND
> parent_inode=?",
> File "/usr/lib/python3.10/site-packages/s3ql/database.py", line 127, in
> get_val
> return self.get_row(*a, **kw)[0]
> File "/usr/lib/python3.10/site-packages/s3ql/database.py", line 145, in
> get_row
> raise NoSuchRowError()
> s3ql.database.NoSuchRowError: Query produced 0 result rows
>
> [...]
>
> this is a strange error. It happens because fsck cannot find the
> lost+found folder when it wants to move an inode into this folder.
> Strangely it could find the folder in previous steps.
>
> The only possibility for this error I see is that the folder "lost+found"
> itself is the inode 3 and thus it gets moved into itself.
> As far as I can see this can only happen when your Sqlite database is
> strange (the view contents_v might not be a view but a table).
>
> Open your S3QL Sqlite database
> (/opt/s3ql-temp/s3c:=2F=2Fs3.eu-central-1.wasabisys.com:443=2Fbucket1-workspace-ad24=2F.db)
>
> directly with the Sqlite CLI <https://sqlite.org/cli.html>and tell us the
> output of the following commands:
> .schema
> SELECT * FROM contents_v WHERE name='lost+found' AND parent_inode=1;
>
empty output
> SELECT * FROM contents LEFT JOIN names ON name_id = names.id WHERE
> names.name='lost+found' AND contents.parent_inode=1;
>
empty output
> The output of the following might also be interesting (it might be many
> rows when your database is seriously broken):
> SELECT contents.rowid, name_id, parent_inode, inode FROM contents LEFT
> JOIN names ON name_id = names.id WHERE names.id IS NULL;
>
plenty (hundereds) of
111506|73767|109628|111980
111507|73768|74828|111981
111508|73769|108875|111982
111509|38816|109630|111983
111510|72572|111983|111984
111511|38816|109635|111985
111512|72572|111985|111986
111513|66691|74914|111987
111514|38816|111987|111988
111515|72572|111988|111989
111516|38816|109638|111990
111517|72572|111990|111991
111518|66700|74914|111992
111519|38888|111992|111993
111520|67252|111993|111994
111521|66701|74914|111995
111522|38816|111995|111996
111523|72568|111996|111997
111524|38816|111992|111998
111525|72572|111998|111999
>
>
> If your local Sqlite database is broken beyond repair (and ONLY in that
> case) you might need to download a backup via s3qladm download-metadata
> <https://www.rath.org/s3ql-docs/man/adm.html> and execute the commands on
> this backup.
>
All previous metadata has the same issue and same result. But s3ql was
running without issue till that time.
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/72c54fd6-fd74-4f00-9d9d-f1c67f5cb293n%40googlegroups.com.
