On Thu, 4 Sep 2014 15:54:20 -0400
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> On Tue, Aug 19, 2014 at 02:38:27PM -0400, Jeff Layton wrote:
> > Allow a privileged userland process to end the v4 grace period early.
> > Any write to the file will cause the v4 grace period to be lifted.
> > The basic idea with this will be to allow the userland client tracking
> > program to lift the grace period once it knows that no more clients
> > will be reclaiming state.
> ...
> > +/**
> > + * write_v4_end_grace - release grace period for nfsd's v4.x lock manager
> > + *
> > + * Input:
> > + * buf: ignored
> > + * size: zero
> > + * OR
> > + *
> > + * Input:
> > + * buf: any value
> > + * size: non-zero length of C string in @buf
> > + * Output:
> > + * passed-in buffer filled with "Y" or "N" with a newline
> > + * and NULL-terminated C string. This indicates whether
> > + * the grace period has ended in the current net
> > + * namespace. Return code is the size in bytes of the
> > + * string. Writing to the file will end the grace period
> > + * for nfsd's v4 lock manager.
> > + */
> > +static ssize_t write_v4_end_grace(struct file *file, char *buf, size_t size)
> > +{
> > + struct net *net = file->f_dentry->d_sb->s_fs_info;
> > + struct nfsd_net *nn = net_generic(net, nfsd_net_id);
> > +
> > + if (size > 0)
> > + nfsd4_end_grace(nn);
>
> Ditto for this one.
>
Sure. I'll fix that up in the next iteration.
> Do we really need separate files for nlm and nfsd?
>
> I think the separate nlm and nfsd grace periods may just be a historical
> mistake.
>
statd and nfsdcltrack are separate programs, and both will need to
"sign off" before we can lift the grace period. With the way that grace
period management works today, I don't see a way to do this without
separate files. If you have an idea in mind for how to unify this
interface then I'm happy to entertain it however...
--
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
