xfs
[Top] [All Lists]

Re: [PATCH 5/8] xfs: implement iomap based buffered write path

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH 5/8] xfs: implement iomap based buffered write path
From: Christoph Hellwig <hch@xxxxxx>
Date: Mon, 2 May 2016 20:25:23 +0200
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx, rpeterso@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160414125814.GE20696@xxxxxxxxxxxxxxx>
References: <1460494382-14547-1-git-send-email-hch@xxxxxx> <1460494382-14547-6-git-send-email-hch@xxxxxx> <20160414125814.GE20696@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
On Thu, Apr 14, 2016 at 08:58:14AM -0400, Brian Foster wrote:
> > +static int
> > +xfs_file_iomap_end_delalloc(
> > +   struct xfs_inode        *ip,
> > +   loff_t                  offset,
> > +   loff_t                  length,
> > +   ssize_t                 written)
> > +{
> > +   struct xfs_mount        *mp = ip->i_mount;
> > +   xfs_fileoff_t           start_fsb;
> > +   xfs_fileoff_t           end_fsb;
> > +   int                     error = 0;
> > +
> > +   start_fsb = XFS_B_TO_FSB(mp, offset + written);
> > +   end_fsb = XFS_B_TO_FSB(mp, offset + length - written);
> > +
> 
> Just skimming over this series... but shouldn't this be offset + length?
> Why walk back from the end of the allocated range?

Because the interface from the core iomap code need to pass the
length of the actually mapped range, and the amount of bytes successfully
written into it to the filesystem, as other filesystems will require
this for their locking.  We need to convert it back at some point,
and it seems more logical here than in the caller.

<Prev in Thread] Current Thread [Next in Thread>