On Thu, Mar 10, 2022 at 01:58:33PM -0800, David Anderson wrote: > Sorry for not replying sooner, things got very busy - I am working on > this now and will hopefully have something tested + uploaded by EOD.
Yeah, ok. I think it's not urgent to us on the kernel side anyway since it's always compatible with old kernels and mtime == ctime == atime as always, we could also clarify later if it doesn't catch the next merge window.. We could delay it to the next release.. Thanks, Gao Xiang > > Best, > > -David > > On Wed, Mar 2, 2022 at 7:57 PM Gao Xiang <[email protected]> wrote: > > > > Hi David, > > > > On Tue, Mar 01, 2022 at 02:09:36PM +0800, Gao Xiang wrote: > > > On Mon, Feb 28, 2022 at 10:02:02PM -0800, David Anderson wrote: > > > > On Mon, Feb 28, 2022 at 9:27 PM Gao Xiang <[email protected]> > > > > wrote: > > > > > > > > > > Yeah, I agree I should think more when I planned to store `ctime' at > > > > > the > > > > > first time [my original thought was to keep metadata time (including > > > > > uid, gid, etc..), so I selected `ctime' instead of `mtime']. > > > > > > > > > > Should we change what's described in > > > > > 'Documentation/filesystems/erofs.rst' > > > > > and even rename i_ctime to i_mtime? > > > > > > > > That's a good idea, I'll repost with a patch to rename to mtime. > > > > Initially I figured it was ok, but the "ctime" name would cause > > > > problems if EROFS ever stores both timestamps. > > > > > > Yeah, I recommend that we could use mtime from now on, but in case that > > > users are confused, we may need add a compatible feature to indicate that. > > > > Would you mind sending a kernel patch to rename them recently if > > you have some free slot? > > > > We're in 5.17-rc7 cycle.. I think we have to prepare patches for > > 5.18 now so we can use new timestamp behavior from 5.18.. > > > > Thanks, > > Gao Xiang > >
