Re: [PATCH 10/10] xfs: use a separate iomap_ops for delalloc writes

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

 



On Wed, Sep 26, 2018 at 11:18:06AM -0400, Brian Foster wrote:
> >  static int
> > -xfs_file_iomap_begin_delay(
> > +xfs_delalloc_iomap_begin(
> 
> Ok, but wouldn't something like xfs_buffered_iomap_begin/end() be a
> better name? Technically a real extent may already exist in this
> codepath, so I find the delalloc name kind of confusing.

The point is that it does a delalloc allocation.  I'd always rather
document what it does than the (current) use case.

Either way I've dropped the patch for now, as it seems a bit pointless
as long as we still don't use delayed allocations for files with
extent size hints.

> > +	xfs_fileoff_t		start_fsb;
> > +	xfs_fileoff_t		end_fsb;
> > +	int			error = 0;
> > +
> > +	if (iomap->type != IOMAP_DELALLOC)
> > +		return 0;
> 
> Any reason we don't continue to filter out !IOMAP_WRITE as well?

We are only using it for writes (or zeroing, but the same logic should
apply there)



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux