diff mbox

[19/20] xfs: implement pNFS export operations

Message ID 20150205135756.GA6386@lst.de (mailing list archive)
State New, archived
Headers show

Commit Message

Christoph Hellwig Feb. 5, 2015, 1:57 p.m. UTC
I've updated the patch and pushed out a new pnfsd-for-3.20-4 branch.

The changes relative to the old one are below:

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Dave Chinner Feb. 6, 2015, 10:20 p.m. UTC | #1
On Thu, Feb 05, 2015 at 02:57:56PM +0100, Christoph Hellwig wrote:
> I've updated the patch and pushed out a new pnfsd-for-3.20-4 branch.
> 
> The changes relative to the old one are below:

Hi Christoph, with these changes I think this is fine to be merged
with the experimental tag attached to it

Acked-by: Dave Chinner <david@fromorbit.com>

I'm expecting the merge window to open on Monday so it's kinda late
to be adding new stuff to the XFS tree and co-ordinating it with the
NFS tree merge - how were you planning to get this to merged?

I've already merged all but the two pNFSD support patches, so
there's some duplicate commits in your pnfsd-for-3.20-4 branch.
i.e. these commits in your tree:

b8d5187 xfs: factor out a xfs_update_prealloc_flags() helper
6d5ca2a xfs: update the superblock using a synchronous transaction in growfs
e3ea93e xfs: pass a 64-bit count argument to xfs_iomap_write_unwritten

are already merged into the xfs for-next branch as:

8add71c xfs: factor out a xfs_update_prealloc_flags() helper
f8079b8 xfs: growfs should use synchronous transactions
d32057f xfs: pass a 64-bit count argument to xfs_iomap_write_unwritten

A straight merge from your tree ends up with both sets of commits in
the history. So a rebase on your side, or me pulling them into the
XFS tree is probably required to keep the history clean.

I didn't really want to add any more to the XFS tree this close to
the merge window opening, but I've already got a regression fix that
needs to be added, so perhaps I'll delay sending Linus a pull
request for a week and just merge all of these XFS changes directly.

What do you think?

Cheers,

Dave.
J. Bruce Fields Feb. 6, 2015, 10:42 p.m. UTC | #2
On Sat, Feb 07, 2015 at 09:20:47AM +1100, Dave Chinner wrote:
> On Thu, Feb 05, 2015 at 02:57:56PM +0100, Christoph Hellwig wrote:
> > I've updated the patch and pushed out a new pnfsd-for-3.20-4 branch.
> > 
> > The changes relative to the old one are below:
> 
> Hi Christoph, with these changes I think this is fine to be merged
> with the experimental tag attached to it
> 
> Acked-by: Dave Chinner <david@fromorbit.com>
> 
> I'm expecting the merge window to open on Monday so it's kinda late
> to be adding new stuff to the XFS tree and co-ordinating it with the
> NFS tree merge - how were you planning to get this to merged?
> 
> I've already merged all but the two pNFSD support patches, so
> there's some duplicate commits in your pnfsd-for-3.20-4 branch.
> i.e. these commits in your tree:
> 
> b8d5187 xfs: factor out a xfs_update_prealloc_flags() helper
> 6d5ca2a xfs: update the superblock using a synchronous transaction in growfs
> e3ea93e xfs: pass a 64-bit count argument to xfs_iomap_write_unwritten
> 
> are already merged into the xfs for-next branch as:
> 
> 8add71c xfs: factor out a xfs_update_prealloc_flags() helper
> f8079b8 xfs: growfs should use synchronous transactions
> d32057f xfs: pass a 64-bit count argument to xfs_iomap_write_unwritten
> 
> A straight merge from your tree ends up with both sets of commits in
> the history. So a rebase on your side, or me pulling them into the
> XFS tree is probably required to keep the history clean.
> 
> I didn't really want to add any more to the XFS tree this close to
> the merge window opening, but I've already got a regression fix that
> needs to be added, so perhaps I'll delay sending Linus a pull
> request for a week and just merge all of these XFS changes directly.
> 
> What do you think?

You'd basically just be pulling my tree (Christoph's is just my nfsd
tree with his patches on top, and I've been testing with exactly that
locally, just putting off pushing it out till we decide this.)

So anyway, fine with me if you want to just pull that into the xfs tree.
Mine's ready whenever, so if I send my pull pretty soon after the merge
window and you send it a little later then we still keep the property
that Linus's merge still has a diffstat only in our respective areas.

(OK, it's a little more complicated because I've got the same
arrangement with jlayton, so the order is jlayton's lock pull, then my
nfsd pull, then your xfs pull.  Is this getting too complicated?
jlayton and I are both ready to so and I think it'd work.)

I'm also fine with duplicating those few patches, or whatever.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Christoph Hellwig Feb. 8, 2015, 1:34 p.m. UTC | #3
On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> You'd basically just be pulling my tree (Christoph's is just my nfsd
> tree with his patches on top, and I've been testing with exactly that
> locally, just putting off pushing it out till we decide this.)
> 
> So anyway, fine with me if you want to just pull that into the xfs tree.
> Mine's ready whenever, so if I send my pull pretty soon after the merge
> window and you send it a little later then we still keep the property
> that Linus's merge still has a diffstat only in our respective areas.
> 
> (OK, it's a little more complicated because I've got the same
> arrangement with jlayton, so the order is jlayton's lock pull, then my
> nfsd pull, then your xfs pull.  Is this getting too complicated?
> jlayton and I are both ready to so and I think it'd work.)
> 
> I'm also fine with duplicating those few patches, or whatever.

Maybe the better idea is to pull the xfs tree in the nfsd tree, but
that would require Dave sending an early pull request so that the
nfsd pull doesn't get delayed.

Or we just defer the pnfsd merge.  While I tried to get it in in time
for 3.20 all the delays during review mean we're really late no and should
punt it to 3.21.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeff Layton Feb. 8, 2015, 2:09 p.m. UTC | #4
On Sun, 8 Feb 2015 14:34:35 +0100
Christoph Hellwig <hch@lst.de> wrote:

> On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> > You'd basically just be pulling my tree (Christoph's is just my nfsd
> > tree with his patches on top, and I've been testing with exactly that
> > locally, just putting off pushing it out till we decide this.)
> > 
> > So anyway, fine with me if you want to just pull that into the xfs tree.
> > Mine's ready whenever, so if I send my pull pretty soon after the merge
> > window and you send it a little later then we still keep the property
> > that Linus's merge still has a diffstat only in our respective areas.
> > 
> > (OK, it's a little more complicated because I've got the same
> > arrangement with jlayton, so the order is jlayton's lock pull, then my
> > nfsd pull, then your xfs pull.  Is this getting too complicated?
> > jlayton and I are both ready to so and I think it'd work.)
> > 
> > I'm also fine with duplicating those few patches, or whatever.
> 
> Maybe the better idea is to pull the xfs tree in the nfsd tree, but
> that would require Dave sending an early pull request so that the
> nfsd pull doesn't get delayed.
> 
> Or we just defer the pnfsd merge.  While I tried to get it in in time
> for 3.20 all the delays during review mean we're really late no and should
> punt it to 3.21.

FWIW, I plan to send a pull request for the locking changes as soon as
the merge window opens. Hopefully that won't be an issue for long...
J. Bruce Fields Feb. 9, 2015, 8:11 p.m. UTC | #5
On Sun, Feb 08, 2015 at 09:09:42AM -0500, Jeff Layton wrote:
> On Sun, 8 Feb 2015 14:34:35 +0100
> Christoph Hellwig <hch@lst.de> wrote:
> 
> > On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> > > You'd basically just be pulling my tree (Christoph's is just my nfsd
> > > tree with his patches on top, and I've been testing with exactly that
> > > locally, just putting off pushing it out till we decide this.)
> > > 
> > > So anyway, fine with me if you want to just pull that into the xfs tree.
> > > Mine's ready whenever, so if I send my pull pretty soon after the merge
> > > window and you send it a little later then we still keep the property
> > > that Linus's merge still has a diffstat only in our respective areas.
> > > 
> > > (OK, it's a little more complicated because I've got the same
> > > arrangement with jlayton, so the order is jlayton's lock pull, then my
> > > nfsd pull, then your xfs pull.  Is this getting too complicated?
> > > jlayton and I are both ready to so and I think it'd work.)
> > > 
> > > I'm also fine with duplicating those few patches, or whatever.
> > 
> > Maybe the better idea is to pull the xfs tree in the nfsd tree, but
> > that would require Dave sending an early pull request so that the
> > nfsd pull doesn't get delayed.
> > 
> > Or we just defer the pnfsd merge.  While I tried to get it in in time
> > for 3.20 all the delays during review mean we're really late no and should
> > punt it to 3.21.
> 
> FWIW, I plan to send a pull request for the locking changes as soon as
> the merge window opens. Hopefully that won't be an issue for long...

This includes Christoph's branch (all but the final xfs commits):

	git://linux-nfs.org/~bfields/linux.git for-3.20

That's what I intend to submit.  Hope that's OK.  Then it's up to Dave
whether he wants to pull that in and include the xfs patches.

Worst case we end up with not-yet-usable pnfs code in 3.20, which
wouldn't be ideal but shouldn't cause any serious problem either.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner Feb. 10, 2015, 12:04 a.m. UTC | #6
On Mon, Feb 09, 2015 at 03:11:54PM -0500, J. Bruce Fields wrote:
> On Sun, Feb 08, 2015 at 09:09:42AM -0500, Jeff Layton wrote:
> > On Sun, 8 Feb 2015 14:34:35 +0100
> > Christoph Hellwig <hch@lst.de> wrote:
> > 
> > > On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> > > > You'd basically just be pulling my tree (Christoph's is just my nfsd
> > > > tree with his patches on top, and I've been testing with exactly that
> > > > locally, just putting off pushing it out till we decide this.)
> > > > 
> > > > So anyway, fine with me if you want to just pull that into the xfs tree.
> > > > Mine's ready whenever, so if I send my pull pretty soon after the merge
> > > > window and you send it a little later then we still keep the property
> > > > that Linus's merge still has a diffstat only in our respective areas.
> > > > 
> > > > (OK, it's a little more complicated because I've got the same
> > > > arrangement with jlayton, so the order is jlayton's lock pull, then my
> > > > nfsd pull, then your xfs pull.  Is this getting too complicated?
> > > > jlayton and I are both ready to so and I think it'd work.)
> > > > 
> > > > I'm also fine with duplicating those few patches, or whatever.
> > > 
> > > Maybe the better idea is to pull the xfs tree in the nfsd tree, but
> > > that would require Dave sending an early pull request so that the
> > > nfsd pull doesn't get delayed.
> > > 
> > > Or we just defer the pnfsd merge.  While I tried to get it in in time
> > > for 3.20 all the delays during review mean we're really late no and should
> > > punt it to 3.21.
> > 
> > FWIW, I plan to send a pull request for the locking changes as soon as
> > the merge window opens. Hopefully that won't be an issue for long...
> 
> This includes Christoph's branch (all but the final xfs commits):
> 
> 	git://linux-nfs.org/~bfields/linux.git for-3.20
> 
> That's what I intend to submit.  Hope that's OK.  Then it's up to Dave
> whether he wants to pull that in and include the xfs patches.

I'm about to send a pull request to Linus for the current XFS tree.
Once that is merged, I'll pull in the remaining xfs-pnfs patches
and send another pull request to Linus after the NFS tree is merged.

Cheers,

Dave.
J. Bruce Fields Feb. 13, 2015, 1:11 a.m. UTC | #7
On Tue, Feb 10, 2015 at 11:04:23AM +1100, Dave Chinner wrote:
> On Mon, Feb 09, 2015 at 03:11:54PM -0500, J. Bruce Fields wrote:
> > On Sun, Feb 08, 2015 at 09:09:42AM -0500, Jeff Layton wrote:
> > > On Sun, 8 Feb 2015 14:34:35 +0100
> > > Christoph Hellwig <hch@lst.de> wrote:
> > > 
> > > > On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> > > > > You'd basically just be pulling my tree (Christoph's is just my nfsd
> > > > > tree with his patches on top, and I've been testing with exactly that
> > > > > locally, just putting off pushing it out till we decide this.)
> > > > > 
> > > > > So anyway, fine with me if you want to just pull that into the xfs tree.
> > > > > Mine's ready whenever, so if I send my pull pretty soon after the merge
> > > > > window and you send it a little later then we still keep the property
> > > > > that Linus's merge still has a diffstat only in our respective areas.
> > > > > 
> > > > > (OK, it's a little more complicated because I've got the same
> > > > > arrangement with jlayton, so the order is jlayton's lock pull, then my
> > > > > nfsd pull, then your xfs pull.  Is this getting too complicated?
> > > > > jlayton and I are both ready to so and I think it'd work.)
> > > > > 
> > > > > I'm also fine with duplicating those few patches, or whatever.
> > > > 
> > > > Maybe the better idea is to pull the xfs tree in the nfsd tree, but
> > > > that would require Dave sending an early pull request so that the
> > > > nfsd pull doesn't get delayed.
> > > > 
> > > > Or we just defer the pnfsd merge.  While I tried to get it in in time
> > > > for 3.20 all the delays during review mean we're really late no and should
> > > > punt it to 3.21.
> > > 
> > > FWIW, I plan to send a pull request for the locking changes as soon as
> > > the merge window opens. Hopefully that won't be an issue for long...
> > 
> > This includes Christoph's branch (all but the final xfs commits):
> > 
> > 	git://linux-nfs.org/~bfields/linux.git for-3.20
> > 
> > That's what I intend to submit.  Hope that's OK.  Then it's up to Dave
> > whether he wants to pull that in and include the xfs patches.
> 
> I'm about to send a pull request to Linus for the current XFS tree.
> Once that is merged, I'll pull in the remaining xfs-pnfs patches
> and send another pull request to Linus after the NFS tree is merged.

Sounds good, thanks.  The nfsd tree's merged now so it should be good to
go if you haven't found any show-stoppers.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner Feb. 13, 2015, 1:54 a.m. UTC | #8
On Thu, Feb 12, 2015 at 08:11:30PM -0500, J. Bruce Fields wrote:
> On Tue, Feb 10, 2015 at 11:04:23AM +1100, Dave Chinner wrote:
> > On Mon, Feb 09, 2015 at 03:11:54PM -0500, J. Bruce Fields wrote:
> > > On Sun, Feb 08, 2015 at 09:09:42AM -0500, Jeff Layton wrote:
> > > > On Sun, 8 Feb 2015 14:34:35 +0100
> > > > Christoph Hellwig <hch@lst.de> wrote:
> > > > 
> > > > > On Fri, Feb 06, 2015 at 05:42:58PM -0500, J. Bruce Fields wrote:
> > > > > > You'd basically just be pulling my tree (Christoph's is just my nfsd
> > > > > > tree with his patches on top, and I've been testing with exactly that
> > > > > > locally, just putting off pushing it out till we decide this.)
> > > > > > 
> > > > > > So anyway, fine with me if you want to just pull that into the xfs tree.
> > > > > > Mine's ready whenever, so if I send my pull pretty soon after the merge
> > > > > > window and you send it a little later then we still keep the property
> > > > > > that Linus's merge still has a diffstat only in our respective areas.
> > > > > > 
> > > > > > (OK, it's a little more complicated because I've got the same
> > > > > > arrangement with jlayton, so the order is jlayton's lock pull, then my
> > > > > > nfsd pull, then your xfs pull.  Is this getting too complicated?
> > > > > > jlayton and I are both ready to so and I think it'd work.)
> > > > > > 
> > > > > > I'm also fine with duplicating those few patches, or whatever.
> > > > > 
> > > > > Maybe the better idea is to pull the xfs tree in the nfsd tree, but
> > > > > that would require Dave sending an early pull request so that the
> > > > > nfsd pull doesn't get delayed.
> > > > > 
> > > > > Or we just defer the pnfsd merge.  While I tried to get it in in time
> > > > > for 3.20 all the delays during review mean we're really late no and should
> > > > > punt it to 3.21.
> > > > 
> > > > FWIW, I plan to send a pull request for the locking changes as soon as
> > > > the merge window opens. Hopefully that won't be an issue for long...
> > > 
> > > This includes Christoph's branch (all but the final xfs commits):
> > > 
> > > 	git://linux-nfs.org/~bfields/linux.git for-3.20
> > > 
> > > That's what I intend to submit.  Hope that's OK.  Then it's up to Dave
> > > whether he wants to pull that in and include the xfs patches.
> > 
> > I'm about to send a pull request to Linus for the current XFS tree.
> > Once that is merged, I'll pull in the remaining xfs-pnfs patches
> > and send another pull request to Linus after the NFS tree is merged.
> 
> Sounds good, thanks.  The nfsd tree's merged now so it should be good to
> go if you haven't found any show-stoppers.

Thanks Bruce. I might have to build a merged tree because one of the
changes from the review modified a header file introduced in the NFS
tree.

I'll see how it goes, and see if I can avoid doing something that
will make Linus yell at me :P

Cheers,

Dave.
Stephen Rothwell Feb. 13, 2015, 2:38 a.m. UTC | #9
Hi Dave,

On Fri, 13 Feb 2015 12:54:22 +1100 Dave Chinner <david@fromorbit.com> wrote:
>
> Thanks Bruce. I might have to build a merged tree because one of the
> changes from the review modified a header file introduced in the NFS
> tree.
> 
> I'll see how it goes, and see if I can avoid doing something that
> will make Linus yell at me :P

If its a syntactic conflict with an obvious resolution, just leave it
(or maybe mention it in the pull request).  It gives him something to
do so he feels useful. :-)

/me notes that I did not see a conflict while merging the xfs tree in
linux-next today ...
Dave Chinner Feb. 15, 2015, 11:25 p.m. UTC | #10
On Fri, Feb 13, 2015 at 01:38:11PM +1100, Stephen Rothwell wrote:
> Hi Dave,
> 
> On Fri, 13 Feb 2015 12:54:22 +1100 Dave Chinner <david@fromorbit.com> wrote:
> >
> > Thanks Bruce. I might have to build a merged tree because one of the
> > changes from the review modified a header file introduced in the NFS
> > tree.
> > 
> > I'll see how it goes, and see if I can avoid doing something that
> > will make Linus yell at me :P
> 
> If its a syntactic conflict with an obvious resolution, just leave it
> (or maybe mention it in the pull request).  It gives him something to
> do so he feels useful. :-)

Heh.

It's not actually a conflict, though. The issue is that some of the
review comments on the XFS side resulted in changes files introduced
from the NFS tree. So the XFS side can't be merged without the NFS
changes being present....

> /me notes that I did not see a conflict while merging the xfs tree in
> linux-next today ...

Because I haven't pushed them yet ;)

Cheers,

Dave.
diff mbox

Patch

diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index 99465ba..48561a0 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -602,8 +602,12 @@  xfs_growfs_data(
 	if (!mutex_trylock(&mp->m_growlock))
 		return -EWOULDBLOCK;
 	error = xfs_growfs_data_private(mp, in);
-	if (!error)
-		mp->m_generation++;
+	/*
+	 * Increment the generation unconditionally, the error could be from
+	 * updating the secondary superblocks, in which case the new size
+	 * is live already.
+	 */
+	mp->m_generation++;
 	mutex_unlock(&mp->m_growlock);
 	return error;
 }
diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
index ab5ee78..7440b40 100644
--- a/fs/xfs/xfs_pnfs.c
+++ b/fs/xfs/xfs_pnfs.c
@@ -15,6 +15,7 @@ 
 #include "xfs_error.h"
 #include "xfs_iomap.h"
 #include "xfs_shared.h"
+#include "xfs_bit.h"
 #include "xfs_pnfs.h"
 
 /*
@@ -48,6 +49,10 @@  xfs_break_layouts(
 	return error;
 }
 
+/*
+ * Get a uniqueue ID including its location so that the client can identify
+ * the exported device.
+ */
 int
 xfs_fs_get_uuid(
 	struct super_block	*sb,
@@ -57,6 +62,10 @@  xfs_fs_get_uuid(
 {
 	struct xfs_mount	*mp = XFS_M(sb);
 
+	printk_once(KERN_NOTICE
+"XFS (%s): using experimental pNFS feature, use at your own risk!\n",
+		mp->m_fsname);
+
 	if (*len < sizeof(uuid_t))
 		return -EINVAL;
 
@@ -75,13 +84,14 @@  xfs_bmbt_to_iomap(
 	struct xfs_mount	*mp = ip->i_mount;
 
 	if (imap->br_startblock == HOLESTARTBLOCK) {
-		iomap->blkno = -1;
+		iomap->blkno = IOMAP_NULL_BLOCK;
 		iomap->type = IOMAP_HOLE;
 	} else if (imap->br_startblock == DELAYSTARTBLOCK) {
-		iomap->blkno = -1;
+		iomap->blkno = IOMAP_NULL_BLOCK;
 		iomap->type = IOMAP_DELALLOC;
 	} else {
-		iomap->blkno = xfs_fsb_to_db(ip, imap->br_startblock);
+		iomap->blkno =
+			XFS_FSB_TO_DADDR(ip->i_mount, imap->br_startblock);
 		if (imap->br_state == XFS_EXT_UNWRITTEN)
 			iomap->type = IOMAP_UNWRITTEN;
 		else
@@ -115,6 +125,12 @@  xfs_fs_map_blocks(
 
 	if (XFS_FORCED_SHUTDOWN(mp))
 		return -EIO;
+
+	/*
+	 * We can't export inodes residing on the realtime device.  The realtime
+	 * device doesn't have a UUID to identify it, so the client has no way
+	 * to find it.
+	 */
 	if (XFS_IS_REALTIME_INODE(ip))
 		return -ENXIO;
 
@@ -190,6 +206,32 @@  out_unlock:
 }
 
 /*
+ * Ensure the size update falls into a valid allocated block.
+ */
+static int
+xfs_pnfs_validate_isize(
+	struct xfs_inode	*ip,
+	xfs_off_t		isize)
+{
+	struct xfs_bmbt_irec	imap;
+	int			nimaps = 1;
+	int			error = 0;
+
+	xfs_ilock(ip, XFS_ILOCK_SHARED);
+	error = xfs_bmapi_read(ip, XFS_B_TO_FSBT(ip->i_mount, isize - 1), 1,
+				&imap, &nimaps, 0);
+	xfs_iunlock(ip, XFS_ILOCK_SHARED);
+	if (error)
+		return error;
+
+	if (imap.br_startblock == HOLESTARTBLOCK ||
+	    imap.br_startblock == DELAYSTARTBLOCK ||
+	    imap.br_state == XFS_EXT_UNWRITTEN)
+		return -EIO;
+	return 0;
+}
+
+/*
  * Make sure the blocks described by maps are stable on disk.  This includes
  * converting any unwritten extents, flushing the disk cache and updating the
  * time stamps.
@@ -209,6 +251,7 @@  xfs_fs_commit_blocks(
 	struct xfs_inode	*ip = XFS_I(inode);
 	struct xfs_mount	*mp = ip->i_mount;
 	struct xfs_trans	*tp;
+	bool			update_isize = false;
 	int			error, i;
 	loff_t			size;
 
@@ -217,8 +260,10 @@  xfs_fs_commit_blocks(
 	xfs_ilock(ip, XFS_IOLOCK_EXCL);
 
 	size = i_size_read(inode);
-	if ((iattr->ia_valid & ATTR_SIZE) && iattr->ia_size > size)
+	if ((iattr->ia_valid & ATTR_SIZE) && iattr->ia_size > size) {
+		update_isize = true;
 		size = iattr->ia_size;
+	}
 
 	for (i = 0; i < nr_maps; i++) {
 		u64 start, length, end;
@@ -248,6 +293,12 @@  xfs_fs_commit_blocks(
 			goto out_drop_iolock;
 	}
 
+	if (update_isize) {
+		error = xfs_pnfs_validate_isize(ip, size);
+		if (error)
+			goto out_drop_iolock;
+	}
+
 	tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_NOT_SIZE);
 	error = xfs_trans_reserve(tp, &M_RES(mp)->tr_ichange, 0, 0);
 	if (error)
@@ -258,11 +309,9 @@  xfs_fs_commit_blocks(
 	xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE);
 
 	xfs_setattr_time(ip, iattr);
-	if (iattr->ia_valid & ATTR_SIZE) {
-		if (iattr->ia_size > i_size_read(inode)) {
-			i_size_write(inode, iattr->ia_size);
-			ip->i_d.di_size = iattr->ia_size;
-		}
+	if (update_isize) {
+		i_size_write(inode, iattr->ia_size);
+		ip->i_d.di_size = iattr->ia_size;
 	}
 
 	xfs_trans_set_sync(tp);
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index ff46bf7..fa05e04 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -187,6 +187,8 @@  struct fid {
 #define IOMAP_MAPPED	0x03	/* blocks allocated @blkno */
 #define IOMAP_UNWRITTEN	0x04	/* blocks allocated @blkno in unwritten state */
 
+#define IOMAP_NULL_BLOCK -1LL	/* blkno is not valid */
+
 struct iomap {
 	sector_t	blkno;	/* first sector of mapping */
 	loff_t		offset;	/* file offset of mapping, bytes */