Re: Test generic/614

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Mon 21-11-22 08:51:43, Darrick J. Wong wrote:
> On Mon, Nov 21, 2022 at 01:32:22PM +0000, Filipe Manana wrote:
> > On Mon, Nov 21, 2022 at 12:37 PM Jan Kara <jack@xxxxxxx> wrote:
> > >
> > > Hello Filipe!
> > 
> > Hi Jan!
> > 
> > >
> > > I have noticed test generic/614 is failing on ext2. The test creates sparse
> > > file, maps it, and writes data to it through mmap. Then it checks i_blocks
> > > has increased. However for ext2 (and other trivial filesystems supporting
> > > sparse files but not implementing delayed allocation) this is bound to fail
> > > because i_block gets incremented only during page writeback.
> > >
> > > So would your btrfs test make sense even if we called fsync(2) before
> > > checking stat(2) results?
> > 
> > Calling fsync before calling stat would defeat the purpose of the test.
> > I.e. the test would pass both with and without the btrfs fix.
> > 
> > So maybe adding the following to the test:
> > 
> > _supported_fs ^ext2
> > 
> > And listing all other filesystems not supporting delayed allocation?
> > 
> > Or adding a _require_delayed_allocation() helper to make it _notrun().
> 
> _require_scratch_delalloc() ?

Yeah, after some experimentation I think I can even sensibly detect
delalloc using filefrag(1) (xfs_io's fiemap command always syncs file
before doing fiemap). I'll give it a shot.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux