[PATCH] erofs: derive atime instead of leaving it empty

[Gao Xiang]

Hi Chao,

On Tue, Nov 03, 2020 at 11:58:42PM +0800, Chao Yu wrote:
> Hi Xiang,
> 
> On 2020-11-3 10:50, Gao Xiang wrote:
> > Hi Chao,
> > 
> > On Sun, Nov 01, 2020 at 03:51:02AM +0800, Gao Xiang wrote:
> > > From: Gao Xiang <hsiangkao at redhat.com>
> > > 
> > > EROFS has _only one_ ondisk timestamp (ctime is currently
> > > documented and recorded, we might also record mtime instead
> > > with a new compat feature if needed) for each extended inode
> > > since EROFS isn't mainly for archival purposes so no need to
> > > keep all timestamps on disk especially for Android scenarios
> > > due to security concerns. Also, romfs/cramfs don't have their
> > > own on-disk timestamp, and squashfs only records mtime instead.
> > > 
> > > Let's also derive access time from ondisk timestamp rather than
> > > leaving it empty, and if mtime/atime for each file are really
> > > needed for specific scenarios as well, we can also use xattrs
> > > to record them then.
> > > 
> > > Reported-by: nl6720 <nl6720 at gmail.com>
> > > [ Gao Xiang: It'd be better to backport for user-friendly concern. ]
> > > Fixes: 431339ba9042 ("staging: erofs: add inode operations")
> > > Cc: stable <stable at vger.kernel.org> # 4.19+
> > > Signed-off-by: Gao Xiang <hsiangkao at redhat.com>
> > 
> > May I ask for some extra free slots to review this patch plus
> > [PATCH 1/4] of
> > https://lore.kernel.org/r/20201022145724.27284-1-hsiangkao@aol.com
> > 
> > since it'd be also in linux-next for a while before sending out
> > to Linus. And the debugging messages may also be an annoying
> > thing for users.
> 
> Sorry for the delay review, will check the details tomorrow. :)

No problem, thanks! If we'd like to submit a -fixes pull request,
it'd be better not to be in the latter half of 5.10 rc... And
considering that it'd be stayed in linux-next for almost a week,
so yeah... (Only these 2 patches are considered for -fixes for now.)

Thanks.
Gao Xiang

> 
> Thanks,
> 
> > 
> > Thanks a lot!
> > 
> > Thanks,
> > Gao Xiang
> > 
>