From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [linux-cifs-client] Re: mount options for selectively disabling parts of CIFS Unix Extensions Date: Tue, 17 Jul 2007 07:57:14 -0400 Message-ID: <20070717075714.78af7b69.jlayton@redhat.com> References: <524f69650707161540n4f4e785ai6c6039d3240456f9@mail.gmail.com> <524f69650707161611r4e29273cn751ffce503bd2d49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-cifs-client@lists.samba.org, samba-technical@lists.samba.org, linux-fsdevel@vger.kernel.org To: "Steve French" Return-path: Received: from mx1.redhat.com ([66.187.233.31]:45914 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755232AbXGQL5H (ORCPT ); Tue, 17 Jul 2007 07:57:07 -0400 In-Reply-To: <524f69650707161611r4e29273cn751ffce503bd2d49@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 16 Jul 2007 18:11:02 -0500 "Steve French" wrote: > I would like opinions on how to handle a specific use question ... > > if the user has mounted e.g. \\server1\shareA (e.g. on a Samba > server) using defaults (and thus gotten support for the Unix > Extensions, but then does a second mount trying to disable Unix > Extensions (e.g. "mount -t cifs //server1/shareB /mnt -o nounix" then > what should the result be: > > > 1) mount fails? If so what return code - there is no easy way to pass > error strings back across mount (get_sb returns an int - a posix > return code) > > 2) mount succeeds, ignoring the "nounix" option but prints a warning to dmesg > > 3) mount succeeds but turns off the Unix Capability bits so no Unix > Extension requests are sent on either shareA or shareB (although the > server behavior will still be a little different than if the client > had not negotiated Unix Extensions at all, at least it will be > different unless the session drops and is reconnected at which time > the server will see the Unix Extensions disabled) > > 4) mount succeeds and no Unix Extension requests are sent on the tree > id for shareB (the requests to shareA are unaffected) > > etc. > > Ideas? > Following the principle of least suprise, then #4 would be best. If that's problematic, then I'd suggest just failing the mount outright with an -EBUSY. NFS has just gone through a not too dissimilar situation (mounting the same export twice with different options). It now fails with -EBUSY in that situation. A new mount option was also introduced (nosharedcache) that makes it fall back on the previous behavior (not sharing superblocks between mounts of the same export). -- Jeff Layton