* Re: [RFC PATCH 2/2] xfs_export_operations.commit_metadata [not found] ` <20100210003337.6021.10942.stgit@case> @ 2010-02-10 9:07 ` Christoph Hellwig 2010-02-10 10:11 ` Christoph Hellwig 2010-02-10 20:15 ` bpm 0 siblings, 2 replies; 5+ messages in thread From: Christoph Hellwig @ 2010-02-10 9:07 UTC (permalink / raw) To: Ben Myers; +Cc: linux-nfs, xfs On Tue, Feb 09, 2010 at 06:33:37PM -0600, Ben Myers wrote: > Here is the commit_metadata export_operation for xfs. We take two dentries and > force the log up to the larger lsn. It looks to me that in nfsd the child is > always modified after the parent so generally we expect the child's lsn to be > larger. If that's not the case we'll just force the entire thing. > > The basic form of this is based upon one of Christoph's suggestions. I'm an > xfs newbie so I'm not very comfortable with it yet. My understanding is that I > need to verify that all of the necessary changes make it into the transations > we're forcing into the log here. I am still looking into that and hopefully > the XFS gurus can continue to provide guidance. Ccing the xfs list would help with that :) Anyway, I think it looks pretty good, but there's quite a few smaller nitpicks: > +STATIC int > +xfs_fs_nfs_commit_metadata( > + struct dentry *parent, > + struct dentry *child) > +{ > + struct xfs_inode *p_xip = NULL, *c_xip = NULL; Normal xfs naming would be dp for the parent, and ip for the child, it would be good to stick to that. > + struct xfs_mount *i_mount = NULL; Normal name all over xfs would be mp. > + } else if (parent && child) { > + p_xip = XFS_I(parent->d_inode); > + c_xip = XFS_I(child->d_inode); > + xfs_ilock(p_xip, XFS_ILOCK_SHARED); > + xfs_ilock(c_xip, XFS_ILOCK_SHARED); If we need to lock both parent and child we need to use xfs_lock_two_inodes to make sure the lock order is correct. > + if (xfs_ipincount(c_xip)) { > + /* > + * AFAICS the child is always modified after the parent > + * in nfsd so should always have a larger lsn. > + */ > + if (c_xip->i_itemp->ili_last_lsn > force_lsn) { > + force_lsn = c_xip->i_itemp->ili_last_lsn; > + } else { > + force_lsn = 0; /* whole thing */ > + } I wouldn't rely on that and always take the larger one. Now with the simplification of always having a non-zero first argument suggested in the previous mail this might be simplified down to: STATIC int xfs_fs_nfs_commit_metadata( struct dentry *parent, struct dentry *child) { struct xfs_inode *dp = XFS_I(parent->d_inode); struct xfs_inode *ip = NULL; struct xfs_mount *mp = dp->i_mount; xfs_lsn_t force_lsn = 0; int error = 0; if (child) { ip = XFS_I(child->d_inode); xfs_lock_two_inodes(dp, ip, XFS_ILOCK_SHARED); } else { xfs_ilock(dp, XFS_ILOCK_SHARED); } if (xfs_ipincount(dp)) force_lsn = dp->i_itemp->ili_last_lsn; if (ip && xfs_ipincount(ip)) force_lsn = max(force_lsn, ip->i_itemp->ili_last_lsn); error = _xfs_log_force_lsn(mp, force_lsn, NULL); if (ip) xfs_iunlock(ip, XFS_ILOCK_SHARED); xfs_iunlock(dp, XFS_ILOCK_SHARED); return error; } Note that _xfs_log_force_lsn is new in the XFS tree, mainline still has _xfs_log_force with an lsn argument. Also note that ->commit_metadata probably should take just two inodes instead of two dentires given the level it operates on, but it shouldn't matter too much. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 2/2] xfs_export_operations.commit_metadata 2010-02-10 9:07 ` [RFC PATCH 2/2] xfs_export_operations.commit_metadata Christoph Hellwig @ 2010-02-10 10:11 ` Christoph Hellwig 2010-02-10 20:15 ` bpm 1 sibling, 0 replies; 5+ messages in thread From: Christoph Hellwig @ 2010-02-10 10:11 UTC (permalink / raw) To: Ben Myers; +Cc: linux-nfs, xfs On Wed, Feb 10, 2010 at 04:07:50AM -0500, Christoph Hellwig wrote: > > + /* > > + * AFAICS the child is always modified after the parent > > + * in nfsd so should always have a larger lsn. > > + */ > > + if (c_xip->i_itemp->ili_last_lsn > force_lsn) { > > + force_lsn = c_xip->i_itemp->ili_last_lsn; > > + } else { > > + force_lsn = 0; /* whole thing */ > > + } > > I wouldn't rely on that and always take the larger one. Or we could use that fact for making the prototype saner: - the commit_metadata only takes a single inode to force out - we make sure to always call in on the child first. For any log based filesystem that will force the parent update, too. - we then call it on the parent, which will be a no-op and thus fast for a log based filesystem, but still provide a fallback if that is not the case. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 2/2] xfs_export_operations.commit_metadata 2010-02-10 9:07 ` [RFC PATCH 2/2] xfs_export_operations.commit_metadata Christoph Hellwig 2010-02-10 10:11 ` Christoph Hellwig @ 2010-02-10 20:15 ` bpm 2010-02-10 21:29 ` Dave Chinner 2010-02-10 21:57 ` Christoph Hellwig 1 sibling, 2 replies; 5+ messages in thread From: bpm @ 2010-02-10 20:15 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-nfs, xfs Howdy, On Wed, Feb 10, 2010 at 04:07:50AM -0500, Christoph Hellwig wrote: > On Tue, Feb 09, 2010 at 06:33:37PM -0600, Ben Myers wrote: > > hopefully > > the XFS gurus can continue to provide guidance. > > Ccing the xfs list would help with that :) I'll cross-post the next rev. ;) > > + if (xfs_ipincount(c_xip)) { > > + /* > > + * AFAICS the child is always modified after the parent > > + * in nfsd so should always have a larger lsn. > > + */ > > + if (c_xip->i_itemp->ili_last_lsn > force_lsn) { > > + force_lsn = c_xip->i_itemp->ili_last_lsn; > > + } else { > > + force_lsn = 0; /* whole thing */ > > + } > > I wouldn't rely on that and always take the larger one. I am concerned that ili_last_lsn will roll over at some point. I haven't figured out how to detect that yet. > Now with the simplification of always having a non-zero first argument > suggested in the previous mail this might be simplified down to: > > STATIC int > xfs_fs_nfs_commit_metadata( > struct dentry *parent, > struct dentry *child) > { > struct xfs_inode *dp = XFS_I(parent->d_inode); > struct xfs_inode *ip = NULL; > struct xfs_mount *mp = dp->i_mount; > xfs_lsn_t force_lsn = 0; > int error = 0; > > if (child) { > ip = XFS_I(child->d_inode); > xfs_lock_two_inodes(dp, ip, XFS_ILOCK_SHARED); > } else { > xfs_ilock(dp, XFS_ILOCK_SHARED); > } > > if (xfs_ipincount(dp)) > force_lsn = dp->i_itemp->ili_last_lsn; > if (ip && xfs_ipincount(ip)) > force_lsn = max(force_lsn, ip->i_itemp->ili_last_lsn); > + if (force_lsn) > error = _xfs_log_force_lsn(mp, force_lsn, NULL); > > if (ip) > xfs_iunlock(ip, XFS_ILOCK_SHARED); > xfs_iunlock(dp, XFS_ILOCK_SHARED); > > return error; > } That's nice! > Note that _xfs_log_force_lsn is new in the XFS tree, mainline still > has _xfs_log_force with an lsn argument. I've been working with Bruce's tree. Not sure how best to handle that. Thanks, Ben _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 2/2] xfs_export_operations.commit_metadata 2010-02-10 20:15 ` bpm @ 2010-02-10 21:29 ` Dave Chinner 2010-02-10 21:57 ` Christoph Hellwig 1 sibling, 0 replies; 5+ messages in thread From: Dave Chinner @ 2010-02-10 21:29 UTC (permalink / raw) To: bpm; +Cc: Christoph Hellwig, linux-nfs, xfs On Wed, Feb 10, 2010 at 02:15:27PM -0600, bpm@sgi.com wrote: > Howdy, > > On Wed, Feb 10, 2010 at 04:07:50AM -0500, Christoph Hellwig wrote: > > On Tue, Feb 09, 2010 at 06:33:37PM -0600, Ben Myers wrote: > > > hopefully > > > the XFS gurus can continue to provide guidance. > > > > Ccing the xfs list would help with that :) > > I'll cross-post the next rev. ;) > > > > + if (xfs_ipincount(c_xip)) { > > > + /* > > > + * AFAICS the child is always modified after the parent > > > + * in nfsd so should always have a larger lsn. > > > + */ > > > + if (c_xip->i_itemp->ili_last_lsn > force_lsn) { > > > + force_lsn = c_xip->i_itemp->ili_last_lsn; > > > + } else { > > > + force_lsn = 0; /* whole thing */ > > > + } > > > > I wouldn't rely on that and always take the larger one. > > I am concerned that ili_last_lsn will roll over at some point. I > haven't figured out how to detect that yet. XFS_LSN_CMP() should be used for LSN comparisons - it handles rollover corectly. > > Now with the simplification of always having a non-zero first argument > > suggested in the previous mail this might be simplified down to: > > > > STATIC int > > xfs_fs_nfs_commit_metadata( > > struct dentry *parent, > > struct dentry *child) > > { > > struct xfs_inode *dp = XFS_I(parent->d_inode); > > struct xfs_inode *ip = NULL; > > struct xfs_mount *mp = dp->i_mount; > > xfs_lsn_t force_lsn = 0; > > int error = 0; > > > > if (child) { > > ip = XFS_I(child->d_inode); > > xfs_lock_two_inodes(dp, ip, XFS_ILOCK_SHARED); > > } else { > > xfs_ilock(dp, XFS_ILOCK_SHARED); > > } > > > > if (xfs_ipincount(dp)) > > force_lsn = dp->i_itemp->ili_last_lsn; > > if (ip && xfs_ipincount(ip)) > > force_lsn = max(force_lsn, ip->i_itemp->ili_last_lsn); So this should be: if (XFS_LSN_CMP(force_lsn, ip->i_itemp->ili_last_lsn) < 0) force_lsn = ip->i_itemp->ili_last_lsn; Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 2/2] xfs_export_operations.commit_metadata 2010-02-10 20:15 ` bpm 2010-02-10 21:29 ` Dave Chinner @ 2010-02-10 21:57 ` Christoph Hellwig 1 sibling, 0 replies; 5+ messages in thread From: Christoph Hellwig @ 2010-02-10 21:57 UTC (permalink / raw) To: bpm; +Cc: linux-nfs, xfs On Wed, Feb 10, 2010 at 02:15:27PM -0600, bpm@sgi.com wrote: > > Note that _xfs_log_force_lsn is new in the XFS tree, mainline still > > has _xfs_log_force with an lsn argument. > > I've been working with Bruce's tree. Not sure how best to handle that. Keep working against it for now, the merge fixup will be easy enough. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-02-10 21:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20100210003220.6021.74943.stgit@case>
[not found] ` <20100210003337.6021.10942.stgit@case>
2010-02-10 9:07 ` [RFC PATCH 2/2] xfs_export_operations.commit_metadata Christoph Hellwig
2010-02-10 10:11 ` Christoph Hellwig
2010-02-10 20:15 ` bpm
2010-02-10 21:29 ` Dave Chinner
2010-02-10 21:57 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox