Re: [PATCH 01/15] xfs: update mount options documentation

Ben Myers
2013-06-28T19:39:59Z

Hey Dave,

On Fri, Jun 28, 2013 at 12:32:04PM +1000, Dave Chinner wrote:
> On Fri, Jun 28, 2013 at 12:09:12PM +1000, Dave Chinner wrote:
> > On Thu, Jun 27, 2013 at 02:08:31PM -0500, Ben Myers wrote:
> > > Hey Dave,
> > >
> > > On Thu, Jun 27, 2013 at 09:48:14AM -0500, Ben Myers wrote:
> > > > On Thu, Jun 27, 2013 at 04:04:45PM +1000, Dave Chinner wrote:
> > > > > From: Dave Chinner <dchinner@redhat.com>
> > > > >
> > > > > Because it's horribly out of date.
> > > > >
> > > > > And mark various deprecated options as deprecated and give them a
> > > > > removal date.
> > > > >
> > > > > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > > > > Reviewed-by: Mark Tinguely <tinguely@sgi.com>
> > > >
> > > > Regarding removal of these mount options and sysctls: initially these all look
> > > > pretty reasonable but we need to be very careful here. I've read some
> > > > discussions on lkml that seem to suggest that such interfaces which have been
> > > > exported to userspace shouldn't be removed at all. Not that I want to keep
> > > > around a bunch of worn out interfaces...
> > > >
> > > > Applied.
> > >
> > > On second thought... Not pushed.
> > >
> > > I'm going to hold off on pushing this one to oss for now because I'm just not
> > > comfortable with it yet. I can pull this in sans the removal notices if you
> > > want. Lets discuss whether the removal of deprecated mount options and sysctls
> > > is acceptable before announcing an intention to remove them. I'm trending no,
> > > but I can be flexible if this really is ok.
> >
> > Mount options are perfectly fine to be removed - they've been given
> > deprecated warnings for quite some time now (the most recent is the
> > delaylog which has been doing that since 3.1 IIRC). So they are all
> > fine to actually remove - 12 months warning is usually considered
> > sufficient.
> >
> > As to the sysctls - they haven't had any effect since 3.5 when the
> > xfsbufd was removed, so it's time to mark them deprecated so we can
> > remove them in a year's time. That gives anyone using them
> > (including distros) plenty of time to fix whatever is using them
> > before they get removed.
> >
> > > I'm thinking of the 3.3 glusterfs and 3.8 pulseaudio reakeage. And I would
> > > really like to have a nice holiday weekend. ;)
> >
> > I think you're being overly paranoid here - I'm simply following the
> > normal deprecation protocol here....
>
> Documenation/ABI/README:
>
> We have four different levels of ABI stability, as shown by the four
> different subdirectories in this location. Interfaces may chang levels
> of stability according to the rules described below.
> ....
> obsolete/
> This directory documents interfaces that are still remaining in
> the kernel, but are marked to be removed at some later point in
> time. The description of the interface will document the reason
> why it is obsolete and when it can be expected to be removed.
>
> I think you'll find that what I done follows this policy.

Thanks. That's exactly the sort of doc I am looking for. I'll check it out.
I really just want to make sure that we're not going to be breaking userspace
by removing these...

> If you really want, I'll move them to Documenation/ABI/obsolete. And, of
> course, if removing them proves to be a problem, as Eric said we can always
> reinstate them or remove the deprecation notices.

I forgot to mention that noatime seems to be missing now. Was that intentional?

-Ben