On Fri, Jun 19, 2020 at 06:28:43PM -0400, J. Bruce Fields wrote: > On Sat, Jun 20, 2020 at 08:10:44AM +1000, Dave Chinner wrote: > > On Fri, Jun 19, 2020 at 04:40:33PM -0400, J. Bruce Fields wrote: > > > On Fri, Jun 19, 2020 at 12:44:55PM +1000, Dave Chinner wrote: > > > > On Thu, Jun 18, 2020 at 10:20:05PM -0400, J. Bruce Fields wrote: > > > > > My memory was that after Jeff Layton's i_version patches, there wasn't > > > > > really a significant performance hit any more, so the ability to turn it > > > > > off is no longer useful. > > > > > > > > Yes, I completely agree with you here. However, with some > > > > filesystems allowing it to be turned off, we can't just wave our > > > > hands and force enable the option. Those filesystems - if the > > > > maintainers chose to always enable iversion - will have to go > > > > through a mount option deprecation period before permanently > > > > enabling it. > > > > > > I don't understand why. > > > > > > The filesystem can continue to let people set iversion or noiversion as > > > they like, while under the covers behaving as if iversion is always set. > > > I can't see how that would break any application. (Or even how an > > > application would be able to detect that the filesystem was doing this.) > > > > It doesn't break functionality, but it affects performance. > > I thought you just agreed above that any performance hit was not > "significant". Yes, but that's just /my opinion/. However, other people have different opinions on this matter (and we know that from the people who considered XFS v4 -> v5 going slower because iversion a major regression), and so we must acknowledge those opinions even if we don't agree with them. That is, if people are using noiversion for performance reasons on filesystems that are not designed/intended to have it permanently enabled, then yanking that functionality out from under them without warning is a Bad Thing To Do. If we want to change this behaviour, the mount option needs to be deprecated and a date/kernel release placed on when it will no longer function (at least a year in the future). When the mount option is used, it needs to log a deprecation warning to the syslog so that users are informed that the option is going away. Then when the deprecation date passes, the mount option can then be ignored by the kernel. > > IOWs, it can make certain workloads go a lot slower in some > > circumstances. And that can result in unexectedly breaking SLAs or > > slow down a complex, finely tuned data center wide workload to the > > point it no longer meets requirements. Such changes in behaviour are > > considered a regression, especially if they result from a change that > > just ignores the mount option that turned off that specific feature. > > I get that, but, what's the threshhold here for a significant risk of > regression? <shrug> I have no real idea because the filesystems that are affected are not ones I'm actively involved in supporting or developing for. That's for the people with domain specific expertise - the individual filesystem maintainers - to decide. > The "noiversion" behavior is kinda painful for NFS. Sure, but that's all you ever get on XFS v4 filesystems and any other filesystem that doesn't support persistent iversion storage. So the NFS implemenations are going to have to live with filesystems without iversion support at all for many more years to come. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
