[oxlog] include files whose creation time predates the range end

[smklein]

oxlog's date_range filter previously tested only a file's mtime against the range. Since mtime is the timestamp of a file's newest line, the end bound was lossy: a file whose content spans the end of the range was dropped whole, even though it might have entries from within the requested bounds. This is often the case for current log files, whose mtime is always recent.

As a concrete example of the old behavior:

• If a caller asks for logs from "4 days ago" to "2 days ago", for a service that has not rotated, but has continued to write to its logs every hour...
• ... then the most recent non-rotated log -- which includes all entries in that requested range! -- would be excluded, because "from an mtime point-of-view, it is more recent than that range".

To mitigate this, the oxlog filter now chooses to include a file when its [created, modified] content span intersects the range. Creation time (crtime) is trusted only when it is no later than the mtime: a copied file's crtime is the time of the copy, not a content bound, so files copied into archive locations with their mtime preserved keep the old mtime-only behavior, as do files where crtime is unavailable.

Once #11113 lands, support bundle zone-log collection inherits this fix through the shared filter.

Commits

[oxlog] Include files whose content span overlaps the date range

Adds the created field to LogFile and rewrites in_date_range to the span-intersection rule. Nothing populates the field yet, so this commit carries no behavior change on its own. Also fixes the DateRange field doc comments, which described the bounds as exclusive while the code has always been inclusive.

Test coverage: a new unit test covers the regression shape directly (created 1:00, mtime 2:00, range ending 1:59 is now included; the same mtime without a creation time stays excluded), the copied-file inversion in both directions, spans entirely outside the range, and inclusive boundary touches. The pre-existing test_daterange_filter continues to pass unchanged, pinning mtime-only behavior.

[oxlog] Populate LogFile creation times

On illumos, crtime is a system attribute (fsattr(7)) rather than part of stat(2), and std::fs::Metadata::created() returns Unsupported. A new crtime module retrieves it with getattrat(3C) from the read-write attribute view and parses the resulting nvlist via illumos-nvpair. On other platforms std::fs::Metadata::created() is used. A missing or unreadable creation time leaves the field None and the file is filtered by mtime alone.

Test coverage: an illumos-gated test creates a file on the ZFS-backed workspace, checks its crtime is readable, recent, and no later than its mtime, and that a missing file yields None rather than an error; run on an illumos workstation along with the rest of the oxlog suite.

[oxlog] Skip the crtime test on filesystems that record no crtime

Makes the illumos-gated test portable to dev environments where the workspace checkout is not on ZFS: it now checks the tempdir's filesystem via statvfs f_basetype and skips with a message rather than failing. Probing pathconf(_PC_SATTR_ENABLED) instead would not work: tmpfs reports system attribute support yet answers getattrat(3C) with an empty attribute list.

Test coverage: both branches of the guard were exercised on an illumos workstation; the ZFS path runs the crtime assertions, and a tempdir on /tmp (tmpfs) takes the skip path.

[smklein]

from a 10,000 ft view, this is the entire change

[smklein]

the lack of support for "created_time" on illumos means we need to do these gymnastics to get the same benefit

[smklein]

This whole test is:

• if we make a file
• can we observe the crtime with the function we just wrote

Should be easy, right? well, we don't totally know the filesystem of the development environment we're operating on. So... we have to check that, to see if it supports the created-time attribute, before continuing.

[wfchandler]

I think this is a good change, but archived logs will still be a problem. Those have their crtime set to the time of migration by sled-agent, not the original file's creation time. Something we can fix in a follow-on PR.

On colo:

# F=system-illumos-propolis-server:default.log.1778804100
# head -1 $F | jq -r .time; tail -1 $F | jq -r .time; ls -l -%all $F
2026-05-14T20:15:10.122754809Z
2026-05-15T00:15:00.944443313Z
-rw-r--r--   1 root     root      904142 May 15 00:18 system-illumos-propolis-server:default.log.1778804100
         timestamp: atime         Aug 21 13:31:08 2026 
         timestamp: ctime         May 15 00:18:29 2026 
         timestamp: mtime         May 15 00:18:29 2026 
         timestamp: crtime         May 15 00:18:29 2026 

[wfchandler]

I will note that this change makes oxlog noticeably slower, but I think the tradeoff is worthwhile.

root@BRM42220051:# time oxlog logs oxz_switch dendrite --current --archived > /dev/null  

real    0m1.048s
user    0m0.357s
sys     0m0.677s

root@BRM42220051:# time ./oxlog-crtime logs oxz_switch dendrite --current --archived > /dev/null

real    0m2.651s
user    0m0.834s
sys     0m1.801s

[smklein]

I really only need this crtime for scenarios where the "modified" time is greater than the end of the requested date range. I did some lazy loading of crtime to speed this up.

I re-ran the benchmarks on dogfood (same machine as you).

For oxlog logs oxz_switch dendrite --current --archived:

binary	real times (3 runs)
oxlog (installed baseline)	1.028s / 0.892s / 0.876s
oxlog-crtime (PR head, unfixed)	2.545s / 2.687s / 2.576s
oxlog-gated (PR + lazy loading)	0.969s / 0.971s / 0.904s

And If I add some explicit date-filtering with -A '4 days ago' -B '2 days ago':

binary	real times (3 runs)
oxlog (installed baseline)	0.774s / 0.852s / 0.889s
oxlog-crtime (PR head, unfixed)	2.500s / 2.570s / 2.519s
oxlog-gated (PR + lazy loading)	0.905s / 0.883s / 0.909s