Message ID | 20150205135756.GA6386@lst.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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.
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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...
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 ...
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 --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 */