Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751493AbVKISoj (ORCPT ); Wed, 9 Nov 2005 13:44:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751495AbVKISoi (ORCPT ); Wed, 9 Nov 2005 13:44:38 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:53122 "EHLO e2.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1751493AbVKISoh (ORCPT ); Wed, 9 Nov 2005 13:44:37 -0500 Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind From: Ram Pai To: Miklos Szeredi Cc: Al Viro , torvalds@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org In-Reply-To: References: <1131464926.5400.234.camel@localhost> Content-Type: text/plain Organization: IBM Message-Id: <1131561849.5400.384.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Nov 2005 10:44:09 -0800 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1979 Lines: 60 On Tue, 2005-11-08 at 07:55, Miklos Szeredi wrote: > > No. As explained in the same earlier threads; without this change the > > behavior of shared-subtrees leads to inconsistency and confusion in some > > scenarios. > > > > Under the premise that no application should depend on this behavior > > (most-recent-mount-visible v/s top-most-mount-visible), > > The strongest argument against was that > > mount foo .; umount . > > would no longer be a no-op. It is a no-op even now. Try it. What you meant was something like this is no-op now? P1: cd /tmp1 P2: mount --bind /var /tmp1 P1: mount --bind /bin . P1: umount . Yes this will not be a noop with my changes. However this behavior is not documented to be a no-op anywhere. right? And 'umount .' really doen't make sense. What does it mean? umount the current mount? or umount of the mount that is mounted on this dentry? My changes just changes one behavior and that is: If multiple mounts are mounted on the same combination the later mounts are obscured by the preceeding mounts. Earlier it was opposite behavior. My biggest complaint about the earlier behavior was that the later mounts obscured not only the earlier mounts on the tuple, but also obscured all the mounts that got stacked on top of the earlier . It seemed totally unnatural, and confusing with shared-subtree. > > Al Viro permitted this change. And this is certainly the right > > behavior. > > Which is a contradiction in term, since you are saying that > applications _do_ depend on it. no. I said application _should_not_ depend on it, because it is a undefined semantics. Sorry I was out yesterday and could reply earlier. RP > > Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/