09:11:59 <ptribble> Oh dear...
09:12:01 <ptribble> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/fs/zfs/zfs_vnops.c#L3146
09:12:13 <ptribble> See also https://www.illumos.org/issues/17413
09:12:14 <fenix> → BUG 17413: ZFS should stop clamping timestamps to 32-bit (New)
09:12:42 <ptribble> Presumably it's as simple as removing that block?
13:04:37 <gemelen> ptribble: interesting, openzfs didn't change it too, yet
13:48:45 <jbk> 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
14:03:45 <oninoshiko> aren't we rapidly approching the point (13 years or so) where if anything is useing 32-bit datetimes it's bad anyway?
15:01:16 <ptribble> That's what IPD 14 is all about
15:01:20 <ptribble> https://github.com/illumos/ipd/blob/master/ipd/0014/README.md
15:01:20 <fenix> → IPD 14: illumos and Y2038 (predraft)
15:02:03 <ptribble> 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.
15:09:28 <gitomat> [illumos-gate] 17329 References to the old rmmount persist in the manual -- Peter Tribble <peter.tribble⊙gc>
15:13:08 <ptribble> I stumbled across it on reddit, so clearly somebody knows our zfs is stuck in time
15:13:28 <ptribble> https://www.reddit.com/r/zfs/comments/1kfigxw/omnios_151054_long_term_stable_opensource_solaris/mqrzzto/
18:24:15 <jclulow> 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.
18:24:31 <richlowe> ptribble: we knew that, I have it in the IPD
18:24:41 <richlowe> as of recently, I admit
18:24:51 <richlowe> ... or I tried to get it added to the IPD, did I miss?
18:25:01 <richlowe> if I did, there are others I found too
19:25:13 <alanc> you can thank https://illumos.org/opensolaris/bugdb/bug.html#!6629604
19:25:14 <fenix> → OpenSolaris issue 6629604: ZFS: lstat64() on ZFS file returns EOVERFLOW (Fix Delivered)
19:27:27 <alanc> we deleted that block in 11.4
19:36:22 <richlowe> yeah, we have a list of things in the IPD that, ideally, people will update as they find more
19:36:28 <richlowe> (or in this case, fix more)
19:36:57 <richlowe> `nfs_allow_preepoch_time` is a good one
19:38:35 <richlowe> alanc might enjoy the comment on `NFS_TIME_T_CONVERT`
19:56:03 <alanc> heh, I hadn't noticed that one yet
20:00:02 <alanc> I don't see https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/bufmod.h#L125 in your list yet, which affects snoop
20:02:05 <alanc> we also found Y2038 problems when testing tshark, but haven't narrowed down where in the libpcap/bpf stack the problem lies yet
20:08:44 <danmcd_> Check "struct bpf_timeval"  in $UTS/common/io/bpf/net/bpf.h   ===> $50 says that's it.
20:18:45 <richlowe> danmcd: can you add that one?
20:19:35 <danmcd> 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.
20:56:03 <alanc> ah, yep, that'd do it
21:03:05 <danmcd> @richlowe ==> done (and some ipd 50 bits added prior to that).
21:03:13 <danmcd> fenix ipd 50
21:03:13 <fenix> IPD 50: ZFS Maintenance and Consumption of OpenZFS Technology (predraft)
21:03:13 <fenix> ↳ https://github.com/illumos/ipd/tree/master/ipd/0050/README.adoc
21:07:45 <alanc> 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