[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201103170421.GB886627@xiangao.remote.csb>
Date: Wed, 4 Nov 2020 01:04:21 +0800
From: Gao Xiang <hsiangkao@...hat.com>
To: Chao Yu <chao@...nel.org>
Cc: Chao Yu <yuchao0@...wei.com>, linux-erofs@...ts.ozlabs.org,
LKML <linux-kernel@...r.kernel.org>, nl6720 <nl6720@...il.com>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH] erofs: derive atime instead of leaving it empty
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@...hat.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@...il.com>
> > > [ Gao Xiang: It'd be better to backport for user-friendly concern. ]
> > > Fixes: 431339ba9042 ("staging: erofs: add inode operations")
> > > Cc: stable <stable@...r.kernel.org> # 4.19+
> > > Signed-off-by: Gao Xiang <hsiangkao@...hat.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
> >
>
Powered by blists - more mailing lists