* 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