On Tue, Jul 02, 2024 at 08:21:42AM -0400, Jeff Layton wrote: > Many of the existing callers of inode_ctime_to_ts are in void return > functions. They're just copying data from an internal representation to > struct inode and assume it always succeeds. For those we'll probably > have to catch bad ctime values earlier. > > So, I think I'll probably have to roll bespoke error handling in all of > the relevant filesystems if we go this route. There are also > differences between filesystems -- does it make sense to refuse to load > an inode with a bogus ctime on NFS or AFS? Probably not. > > Hell, it may be simpler to just ditch this patch and reimplement > mgtimes using the nanosecond fields like the earlier versions did. Thatdoes for sure sound simpler. What is the big advantage of the ktime_t? Smaller size?
