ref: 50cfd4075ac00a6047dbbedd73ee7867ac5d6889
parent: 09b5471a8feeda723b1fe2f951921a4302a312f0
author: Noam Preil <noam@pixelhero.dev>
date: Thu Sep 18 19:39:00 EDT 2025
fix disk key reporting, error handling
--- a/disk.c
+++ b/disk.c
@@ -73,7 +73,6 @@
u8int blocks;
uchar *buf;
VtISect *s_sect;
- u16int key;
u32int magic;
bucket = U32GET(score) / index.div;
u16int n, off;
@@ -80,15 +79,14 @@
s_sect = &index.sects[isectforbucket(bucket)];
bucket -= s_sect->start;
if(!cachelookup((char**)&buf, s_sect->cacheindex, bucket)){- fprint(2, "reading from disk...\n");
if(pread(s_sect->fd, (char*)buf, s_sect->blocksize, s_sect->blockbase + (bucket << s_sect->blocklog)) != s_sect->blocksize){- cacheunlock(key, bucket);
+ cacheunlock(s_sect->cacheindex, bucket);
werrstr("Failed to read bucket");return 0;
}
}
n = U16GET(buf);
- fprint(2, "appending to bucket %d, key %08x, n %d\n", bucket, key, n);
+ fprint(2, "appending to bucket %d, key %08x, n %d\n", bucket, s_sect->cacheindex, n);
if(s_sect->bucketmagic){magic = U32GET(buf+2);
if(magic == 0){--- a/notebook
+++ b/notebook
@@ -3449,3 +3449,48 @@
initialized, launching server...overridding tcp address for simultaneous testing! tcp!*!14011...
The issue is completely gone. Can we rewrite that data now using neoventi, and access with venti?
+
+...but also, wait a second, only one unindexed clump? Did - ahhhh venti synced our clumps to the arenainfo for us, probably?
+
+% vac reformschem.png
+
+Hash differs now, but that makes sense, because vac uses wtime in the tree, I believe.
+
+% vacfs $HASH
+% page ...
+
+the schematic shows up just fine!
+
+...but if I then try and access with venti,
+ % vacfs vac:668a47eef20d5a9332dcfbab6a6228291dcf5e72
+vacfs: vacfsopen: no block with score 668a47eef20d5a9332dcfbab6a6228291dcf5e72/16 exists
+
+clumps: 192, 0
+clump 2 is broken, at address 98418: arenarepair: magic is incorrect. If this block was not written by old-venti, you may have a problem.
+
+....annnnnd _there's_ a problem found with us writing, again. Cool. Love it.
+
+...all the WPTRs show
+appending to bucket 371, key 00000000, n 1
+
+key is 0. That's... not right, I'm fairly sure. Need to double check.
+
+entry found in bucket: arena 0, offset 1570072
+
+That's the first result from when vacfs ran successfully...
+
+corruption detected: the last 190 clumps are corrupt. Dropping them.
+ addr dropped from 1516852 to 98380
+
+Also, we _did_ write _some_ clumps successfully, just not all. Some edge case, likely?
+
+Let's start with the key, that is known to look wrong, so let's look.
+
+That - that key is _definitely_ uninitialized at use.
+
+uint16_t key
+if(pread fails)
+ cacheunlock(key)
+fprint("appending to ...", key)+
+the later cacheunlock uses s_sect->cacheindex directly, not `key`, so this might just be a bad log (and bad error handling!) cachelookup is also using that cacheindex directly.
--
⑨