Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/4/4 0:08, Jaegeuk Kim wrote: > On 04/03, Chao Yu wrote: >> On 2018/4/3 13:23, Jaegeuk Kim wrote: >>> On 04/03, Chao Yu wrote: On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/4/4 0:08, Jaegeuk Kim wrote: > On 04/03, Chao Yu wrote: >> On 2018/4/3 13:23, Jaegeuk Kim wrote: >>> On 04/03, Chao Yu wrote: On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/4/3 13:23, Jaegeuk Kim wrote: > > On 04/03, Chao Yu wrote: > >> On 2018/3/31 0:30, Jaegeuk Kim wrote: > >>> Change log from v1: > >>> - add more description > >>> > >>> This fixes xfstests/generic/392. > >>> > >>> The failure was caused by different times

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/4/3 13:23, Jaegeuk Kim wrote: > > On 04/03, Chao Yu wrote: > >> On 2018/3/31 0:30, Jaegeuk Kim wrote: > >>> Change log from v1: > >>> - add more description > >>> > >>> This fixes xfstests/generic/392. > >>> > >>> The failure was caused by different times

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/4/3 13:23, Jaegeuk Kim wrote: > On 04/03, Chao Yu wrote: >> On 2018/3/31 0:30, Jaegeuk Kim wrote: >>> Change log from v1: >>> - add more description >>> >>> This fixes xfstests/generic/392. >>> >>> The failure was caused by different times between 1) one marked in the last >>> fsync(2)

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/4/3 13:23, Jaegeuk Kim wrote: > On 04/03, Chao Yu wrote: >> On 2018/3/31 0:30, Jaegeuk Kim wrote: >>> Change log from v1: >>> - add more description >>> >>> This fixes xfstests/generic/392. >>> >>> The failure was caused by different times between 1) one marked in the last >>> fsync(2)

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/3/31 0:30, Jaegeuk Kim wrote: > > Change log from v1: > > - add more description > > > > This fixes xfstests/generic/392. > > > > The failure was caused by different times between 1) one marked in the last > > fsync(2) call and 2) the other given by

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/3/31 0:30, Jaegeuk Kim wrote: > > Change log from v1: > > - add more description > > > > This fixes xfstests/generic/392. > > > > The failure was caused by different times between 1) one marked in the last > > fsync(2) call and 2) the other given by

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The failure was caused by different times between 1) one marked in the last > fsync(2) call and 2) the other given by roll-forward recovery after power-cut. > The reason

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 2018/3/31 0:30, Jaegeuk Kim wrote: > Change log from v1: > - add more description > > This fixes xfstests/generic/392. > > The failure was caused by different times between 1) one marked in the last > fsync(2) call and 2) the other given by roll-forward recovery after power-cut. > The reason

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

Change log from v1: - add more description This fixes xfstests/generic/392. The failure was caused by different times between 1) one marked in the last fsync(2) call and 2) the other given by roll-forward recovery after power-cut. The reason was that we skipped updating inode block at 1), since

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

Change log from v1: - add more description This fixes xfstests/generic/392. The failure was caused by different times between 1) one marked in the last fsync(2) call and 2) the other given by roll-forward recovery after power-cut. The reason was that we skipped updating inode block at 1), since