nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

fs: timestamps come from the clock, and /proc/fsstat says how full the tables are

Browse source 
Everything created after boot was stamped 1970. know() in SchFS and now_sec() in
the v1 filesystem both returned uptime(), under comments saying the kernel had no
wall clock -- which stopped being true when time_init() started reading the RTC.
The comments outlived the condition they described.

Two errors, and the second is the less obvious: uptime() counts 10 ms *ticks* and
they were being used as *seconds*, so a node created 0.6 s into boot read back as
00:01:00 and the clocks ran a hundred times too fast. Both now go through
wallclock(), which exists precisely so nothing can disagree with gettimeofday
about the time. Confirmed against the RTC line from the same boot.

The occupancy counters are the instrumentation docs/plan/roadmap.md asked for
while hunting the ls -lR hang: inode, file and pinned-buffer counts with a
high-water mark each, maintained at the 0->1 and 1->0 transitions rather than by
scanning, so they cost one increment on a path that already holds the table's
lock.

The peaks are the diagnostic. A live count only describes the moment you looked,
and a reference leak is invisible in it right up until the table is full -- at
which point iget() panics and filealloc() returns 0, which is where the trail
used to go cold.

What they measured: across ten iterations of ls -lR with writes interleaved, 33
execs and 13378 tree descents, inode_peak stayed at 9/200, file_peak at 9/512 and
buf_pinned_peak at 1/256, with the SchFS bracket unlocked throughout. That
eliminates the roadmap's own hypothesis -- "a lock or reference-count leak
somewhere in the *at() paths" -- and the hang did not reproduce. It is very
likely fixed in passing by the *at() dirfd rewrite, the getdents cookie rewrite
or SchFS becoming the root, all of which landed after it was reported.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
Nexoniarz 2026-09-12 17:14:14 +02:00
commit fc0a7c6f4e
5 changed files with 78 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

25
include/fsstat.h
View file

@ -41,6 +41,31 @@ struct fsstat {
// exec(2), which on this system means reading an 800 KB multicall binary.
uint64 exec_calls;
uint64 exec_cycles;
// ---------------------------------------------------------------------
// Table occupancy, for finding leaks.
//
// `_used` is the live count; `_peak` is the high-water mark, and the peak is
// the number that answers the question. A live count only tells you about the
// moment you looked, and a reference leak is invisible in it right up until
// the table is full -- at which point iget() panics and filealloc() returns
// 0, which is where the trail goes cold.
//
// Maintained at the 0->1 and 1->0 transitions rather than by scanning, so
// they cost one increment on a path that already holds the relevant lock.
//
// What to watch: run a long ls-heavy session and read /proc/fsstat between
// commands. A peak that climbs and never comes back down after the commands
// finish is the leak, and which of the three it is says where to look.
uint64 inode_used, inode_peak;
uint64 file_used, file_peak;
uint64 buf_pinned, buf_pinned_peak;
};
// Bump a (used, peak) pair. Callers hold the table's own lock already.
#define FSSTAT_TAKE(used, peak) \
do { if (++(used) > (peak)) (peak) = (used); } while (0)
#define FSSTAT_DROP(used) \
do { if ((used) > 0) (used)--; } while (0)
extern struct fsstat fsstat;