On Tue, Feb 14, 2023 at 12:13:19AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 14, 2023 at 04:51:13PM +1100, Dave Chinner wrote:
> > index 958e4bb2e51e..fb718a5825d5 100644
> > --- a/fs/xfs/libxfs/xfs_bmap.c
> > +++ b/fs/xfs/libxfs/xfs_bmap.c
> > @@ -4553,8 +4553,12 @@ xfs_bmapi_convert_delalloc(
> > * should only happen for the COW fork, where another thread
> > * might have moved the extent to the data fork in the meantime.
> > */
> > - WARN_ON_ONCE(whichfork != XFS_COW_FORK);
> > - error = -EAGAIN;
> > + if (whichfork != XFS_COW_FORK) {
> > + xfs_bmap_mark_sick(ip, whichfork);
> > + error = -EFSCORRUPTED;
> > + } else {
> > + error = -EAGAIN;
> > + }
>
> The comment above should probably be expanded a bit on what this means
> for a non-cow fork extent and how we'll handle it later.
>
> > + if (error) {
> > + if ((error == -EFSCORRUPTED) || (error == -EFSBADCRC))
>
> Nit: no need for the inner braces.
>
> >
> > + /*
> > + * If the inode is sick, then it might have delalloc extents
> > + * within EOF that we were unable to convert. We have to punch
> > + * them out here to release the reservation as there is no
> > + * longer any data to write back into the delalloc range now.
> > + */
> > + if (!xfs_inode_is_healthy(ip))
> > + xfs_bmap_punch_delalloc_range(ip, 0,
> > + i_size_read(VFS_I(ip)));
>
> Is i_size_read the right check here? The delalloc extent could extend
> past i_size if i_size is not block aligned. Can't we just simply pass
> (xfs_off_t)-1 here?
Probably, we just killed all the delalloc blocks beyond eof via
xfs_free_eofblocks() in the line above this, so I didn't seem
necessary to try to punch blocks beyond EOF for this case. Easy
enough to do to be safe, just need a comment update to go with
it....
Cheers,
Dave.
>
>
--
Dave Chinner
david@xxxxxxxxxxxxx
