On Oct 13, 2010, at 3:31 PM, Steve Dickson wrote: > On 10/13/2010 02:56 PM, Jeff Layton wrote: >> On Wed, 13 Oct 2010 14:45:57 -0400 >> Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >>> I would say send the UMNT, since it does not cause any pain to send it >>> verses the pain that could be cause by not sending it... >>> >>> This is a perfect example of fixing something that is not >>> broken... We can put our energy in better place that worrying >>> about things like this... IMHO... >> >> But it *is* broken. As Chuck pointed out, the main problem is that mtab >> handling is broken on remounts. That's a real problem that needs to be >> fixed. > Fine... Lets just focus on that issue... Actually... Removing UMNT support _is_ the proposed fix for the "-o remount" issue. The reason we depend on /etc/mtab is because umount needs to know how to do the unmount. A "-o remount" wipes that information. It turns out that there is no correct implementation of remount rewriting the options in /etc/mtab. utils-linux-ng does not even get this right, and mount(8) claims that /etc/mtab will not be reliable after a remount. If we no longer have to perform a UMNT, then there is no need to worry about the contents of /etc/mtab, for any reason, and it can go away. I believe we are the only file system that is holding up the complete removal of /etc/mtab. I think there's no reason to keep UMNT in user space; it simply can never work correctly there. I believe a kernel space implementation would be simple, and would work correctly much more often than user space UMNT does now. I don't agree with Trond that we should not do it there, but that's an argument I can't win. >> I agree that our time is better spent elsewhere. I just think that we >> ought to make that happen by eliminating the unnecessary umount helper. >> The less code that we need to maintain, the better... > In general I agree... but removing functionality (i.e. umount.nfs) > can cause more pain than just leaving things as is... Is there any specific evidence that there will be pain if umount.nfs is removed? I can't think of any use case it would harm. It's already broken in many cases, and we have never heard of a specific application complaint about it. If there had been a complaint we would have fixed it already. UMNT is clearly vestigial. -- chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
