and the .schema
sqlite> .schema
CREATE TABLE objects (
id INTEGER PRIMARY KEY AUTOINCREMENT,
refcount INT NOT NULL,
size INT NOT NULL
);
CREATE TABLE sqlite_sequence(name,seq);
CREATE TABLE blocks (
id INTEGER PRIMARY KEY,
hash BLOB(32) UNIQUE,
refcount INT,
size INT NOT NULL,
obj_id INTEGER NOT NULL REFERENCES objects(id)
);
CREATE TABLE inodes (
-- id has to specified *exactly* as follows to become
-- an alias for the rowid.
id INTEGER PRIMARY KEY AUTOINCREMENT,
uid INT NOT NULL,
gid INT NOT NULL,
mode INT NOT NULL,
mtime_ns INT NOT NULL,
atime_ns INT NOT NULL,
ctime_ns INT NOT NULL,
refcount INT NOT NULL,
size INT NOT NULL DEFAULT 0,
rdev INT NOT NULL DEFAULT 0,
locked BOOLEAN NOT NULL DEFAULT 0
);
CREATE TABLE inode_blocks (
inode INTEGER NOT NULL REFERENCES inodes(id),
blockno INT NOT NULL,
block_id INTEGER NOT NULL REFERENCES blocks(id),
PRIMARY KEY (inode, blockno)
);
CREATE TABLE symlink_targets (
inode INTEGER PRIMARY KEY REFERENCES inodes(id),
target BLOB NOT NULL
);
CREATE TABLE names (
id INTEGER PRIMARY KEY,
name BLOB NOT NULL,
refcount INT NOT NULL,
UNIQUE (name)
);
CREATE TABLE contents (
rowid INTEGER PRIMARY KEY AUTOINCREMENT,
name_id INT NOT NULL REFERENCES names(id),
inode INT NOT NULL REFERENCES inodes(id),
parent_inode INT NOT NULL REFERENCES inodes(id),
UNIQUE (parent_inode, name_id)
);
CREATE TABLE ext_attributes (
inode INTEGER NOT NULL REFERENCES inodes(id),
name_id INTEGER NOT NULL REFERENCES names(id),
value BLOB NOT NULL,
PRIMARY KEY (inode, name_id)
);
CREATE VIEW contents_v AS
SELECT * FROM contents JOIN names ON names.id = name_id
/* contents_v(rowid,name_id,inode,parent_inode,id,name,refcount) */;
CREATE VIEW ext_attributes_v AS
SELECT * FROM ext_attributes JOIN names ON names.id = name_id
/* ext_attributes_v(inode,name_id,value,id,name,refcount) */;
CREATE TABLE sqlite_stat1(tbl,idx,stat);
On Wednesday, 23 March 2022 at 16:47:32 UTC+1 Radek AD24 Šalomon wrote:
> 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/be7c29d0-730a-4b51-a49b-4c87e650e5cfn%40googlegroups.com.
