On Thu, May 25, 2017 at 04:25:24PM +0200, Jan Kara wrote: > Currently, extent manipulation operations such as hole punch, range > zeroing, or extent shifting do not record the fact that file data has > changed and thus fdatasync(2) has a work to do. As a result if we crash > e.g. after a punch hole and fdatasync, user can still possibly see the > punched out data after journal replay. Test generic/392 fails due to > these problems. > > Fix the problem by properly marking that file data has changed in these > operations. > > CC: stable@xxxxxxxxxxxxxxx > Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622 > Signed-off-by: Jan Kara <jack@xxxxxxx> Thanks, applied. - Ted