On Tue, Nov 12, 2019 at 4:02 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Tue, Nov 12, 2019 at 4:16 PM Christoph Hellwig <hch@xxxxxx> wrote: > > > > Amir just send another patch dealing with the time stamps. I'd suggest > > you chime into the discussion in that thread. > > That's right I just posted the ext4 style extend to 34bits yesterday [1], > but I like your version so much better, so I will withdraw mine. Thanks! I guess we probably want part of both in the end. I considered adding wrappers for encoding and decoding the timestamp like yours but in the end went with open-coding that part. The difference is pretty minimal, should we leave it with the open-coded addition? One part that I was missing (as described in my changelog) is any versioning or feature flag, including the dynamically set sb->s_time_max value. From looking at your patch, I guess this is something we want. > Sorry I did not CC you nor Deepa nor y2038 list. > I did not think you were going to actually deal with specific filesystems. I was not going to, but in the process of cleaning up the remaining ioctls I came to xfs last week and thought it would be silly to extend the uapi but not the file system ;-) > I'd also like to hear people's thoughts about migration process. > Should the new feature be ro_compat as I defined it or incompat? > > If all agree that Arnd's format change is preferred, I can assist with > xfsprogs patches, tests or whatnot. Awesome, that would be great indeed! Arnd