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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 28, 2013 at 02:39:59PM -0500, Ben Myers wrote:
> 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@xxxxxxxxxx>
> > > > > > 
> > > > > > 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@xxxxxxxxxx>
> > > > > > Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
> > > > > 
> > > > > 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?

Yes - it's not an XFS mount option - it's handled by the VFS and
documented as a common mount option for all filesystems just like
nodiratime, relatime, strictatime, sync, dirsync, nosuid, noexec,
etc. IOWs, there's no need to document it as an XFS specific mount
option....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux