On 6/28/13 11:39 AM, Geoffrey Wehrman wrote:
> 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:
> | > 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.
> I hardly consider 12 years to be sufficient. I have no problem with
12 years, really? Maybe you meant months. I hope you meant months!
> deprecating and disabling mount options so that they are ineffective,
> but removing them so that an administrator gets an error when upgrading
> his system is irresponsible product management, especially when it
> requires almost no effort to keep the deprecated, disabled interface.
> You move to newer kernels much faster than most people. Doesn't Red Hat
> still support Red Hat 5? How old is that kernel?
Yes, of course we do - it's based on 2.6.18, which was released in 2006.
But I'm not sure how that's relevant?
> One of the reasons I
> and others dread upgrading systems is because there are always
> interfaces that change, always data conversions that have to be run,
> always new processes to learn. I realize that XFS is still an evolving
> filesystem, by historically one of its greatest achievements has been
> that of backward compatibility. When XFS was ported from IRIX to Linux,
> the same filesystem could be used without any conversion. Why force a
> user to modify his fstab just because he has upgraded his kernel?
That's quite a leap; year-long, orderly deprecation of mount options is
hardly comparable breaking on-disk formats during a port.
But of course we (RHEL) take migration seriously too, which is why we have
migration guides to help admins make the transition, documenting the many
necessary changes when doing a large upgrade.
For the big jumps that come from distro upgrades, they can document these
changes along with myriad others.
For people rolling their own kernels & updating every now and then, they'll
have a 12 month window of warnings to give them time to adapt and/or
request that the option be kept.
If you're upgrading a kernel which is older than 12 months, quite frankly
you'll have a fair bit more to do than worry about than "irixsgid" mount
options when you make that big a jump. Updating fstab will be the least
of your worries.
There is no need to accumulate dead, no-op code in xfs. It's one
of the reasons closed-source proprietary code ends up being so crufty
and hard to maintain - years and years of accumulated gunk nobody dares
touch. We can do better than that.
Deprecating old code in an orderly & documented fashion is a longstanding
best practice in the linux kernel. And we've already removed other XFS
mount options, and the world didn't end:
f538d4da8d521746ca5ebf8c1a8105eb49bfb45e (removed nologflush mount option)
288699fecaffa1ef8f75f92020cbb593a772e487 xfs: drop dmapi hooks (removed dmapi
a64afb057b607c04383ab5fb53c51421ba18c434 xfs: remove obsolete osyncisosync
a19d9f887d81106d52cacbc9930207b487e07e0e xfs: kill ino64 mount option
We've removed sysctls too:
e0b8e8b65d578f5d5538465dff8392cf02e1cc5d [XFS] remove restricted chown
parameter from xfs linux
Seriously - this is how we maintain code.
> | > 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
> | > > 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 change 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. 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.
> It is great that Linux has a documented life cycle for kernel to userspace
> interfaces. These are guidelines for the minimum requirements. Move the
> mount options to obsolete. I have no problems with making mount options
> obsolete. Remove them and people will make a big fuss.
Well, AFAIK nobody fussed over nodelaylog, ino64, osyncisosync, or the
dmapi options. Nobody fussed over the restrict_chown sysctl.
And as I mentioned earlier, the whole point of the deprecation period is to let
people speak up if they need it. Ext4 put options back when people fussed; we
can do that too as needed. (Unless you consider this a pre-emptive fuss. ;)
The spirit of the fuss-rule, though, is that people actually *using* it can
fuss; meta-fussing hasn't traditionally counted.)
I understand that you don't want to surprise or inconvenience users; that
should be balanced with keeping the code current, orderly & un-crufty.
A 12-month notification & RFC period strikes that balance well, I think.