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 mount options) a64afb057b607c04383ab5fb53c51421ba18c434 xfs: remove obsolete osyncisosync mount option 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 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 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. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
