Oh dear...

See also illumos.org/issues/17413

→ BUG 17413: ZFS should stop clamping timestamps to 32-bit (New)

Presumably it's as simple as removing that block?

ptribble: interesting, openzfs didn't change it too, yet

annoyingly, it seems that most of the upstack callers of it would know if they're being invoked w/ largefile support or not, but don't seem to be able to pass that info down (so we could conditionally allow it)... the resulting file would fail a 32-bit stat(2), but we already have plenty of precedence for that happening

aren't we rapidly approching the point (13 years or so) where if anything is useing 32-bit datetimes it's bad anyway?

That's what IPD 14 is all about

→ IPD 14: illumos and Y2038 (predraft)

I might have missed it (searching issues isn't perfect) but I couldn't find this issue logged already, which I found a little surprising.

[illumos-gate] 17329 References to the old rmmount persist in the manual -- Peter Tribble <peter.tribble⊙gc>

I stumbled across it on reddit, so clearly somebody knows our zfs is stuck in time

oninoshiko: Yes. I think there will be a bit of a shoulder 10 years before the cutoff, because I suspect it's relatively common for at least some software to try to reason about dates a round 10 years from the present, etc.

ptribble: we knew that, I have it in the IPD

as of recently, I admit

... or I tried to get it added to the IPD, did I miss?

if I did, there are others I found too

you can thank illumos.org/opensolaris/bugdb/bug.html#!6629604

→ OpenSolaris issue 6629604: ZFS: lstat64() on ZFS file returns EOVERFLOW (Fix Delivered)

we deleted that block in 11.4

yeah, we have a list of things in the IPD that, ideally, people will update as they find more

(or in this case, fix more)

`nfs_allow_preepoch_time` is a good one

alanc might enjoy the comment on `NFS_TIME_T_CONVERT`

heh, I hadn't noticed that one yet

I don't see github.com/illumos/illumos-gate/blo…sr/src/uts/common/sys/bufmod.h#L125 in your list yet, which affects snoop

we also found Y2038 problems when testing tshark, but haven't narrowed down where in the libpcap/bpf stack the problem lies yet

Check "struct bpf_timeval" in $UTS/common/io/bpf/net/bpf.h ===> $50 says that's it.

danmcd: can you add that one?

Yes... if I forget, please remind me? I'm mid-something right now and I might have to leave before I finish said something or immediately after.

ah, yep, that'd do it

@richlowe ==> done (and some ipd 50 bits added prior to that).

fenix ipd 50

IPD 50: ZFS Maintenance and Consumption of OpenZFS Technology (predraft)

↳ github.com/illumos/ipd/tree/master/ipd/0050/README.adoc

oh, and there's also at least one Y2036 problem in rdate/in.timed, which we "fixed" by putting a note in the man page warning it won't work past February 7, 2036 but that you really should have switched to NTP by now anyway