From owner-freebsd-fs@FreeBSD.ORG Sat May 16 07:59:24 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 122D0E62 for ; Sat, 16 May 2015 07:59:24 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98F8D160B for ; Sat, 16 May 2015 07:59:23 +0000 (UTC) Received: by wibt6 with SMTP id t6so15810301wib.0 for ; Sat, 16 May 2015 00:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=xtRvjzNuVAn3D4qE4uL5DLFdqpFYMHHczJ3sPAoJwdw=; b=iAcFImPnJgeJpmK4sXX161DRLZzcd5pIVkZOBC/IBZ0hi2W3dvcCbaNx9ppXdYJ9W5 n7SgUPcNa9iUnxQRcXlbSXicJnnq3KcNLvMeZ9eceb8LpJVRcIcKYhFO/ijnJsjWQA0O mApmgpRe/MGQ2sXN2RCrf+AiOf0o9XfAbeUYVOlqFH0KCXL1AptetukE3KX+FHkReJZ4 QJNt3jYqbf+n35l7Bsq+Lf0SjR2F250oY5mPV8S8MiYqC+qi1EYCPmZI5SKtfbTlruQX 1RxjxKRdP4S9RSvF10noyLM1WBIn19HL0kGppDZtlcPaNB7LxEObVCkrIe2+pjZqFIBu 9oiA== X-Received: by 10.194.5.103 with SMTP id r7mr24890495wjr.47.1431763162174; Sat, 16 May 2015 00:59:22 -0700 (PDT) Received: from brick.home (aegz87.neoplus.adsl.tpnet.pl. [79.186.181.87]) by mx.google.com with ESMTPSA id hn7sm1751164wib.5.2015.05.16.00.59.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 00:59:21 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 16 May 2015 09:59:19 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Rick Macklem Cc: FreeBSD Filesystems Subject: nmount(2) vs 64 bit flags [Was: Re: RFC: should automounted file systems be exportable?] Message-ID: <20150516075919.GB4528@brick.home> Mail-Followup-To: Rick Macklem , FreeBSD Filesystems References: <20150512074602.GA93864@brick.home> <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 07:59:24 -0000 On 0512T0750, Rick Macklem wrote: > Edward Napierala wrote: > > On 0511T2217, Rick Macklem wrote: > > > A recent bug was reported related to mountd and the > > > "automounted" flag. > > > > > > Loosely related to this is the question... > > > Should automounted file systems be exportable? > > > > > > I haven't tested it, but I suspect that it would be > > > broken and the NFS server will reply NFSERR_STALE > > > after the file system has been dismounted. > > > > > > So, should I patch mountd so that it won't export > > > automounted file systems? > > > > Exporting an automounted filesystem doesn't seem to make much sense, > > I agree, but I'm not sure if adding code to prevent it is such > > a good idea. If the user asks for it, by putting it into exports(5), > > it's his fault; the only thing this code could add would be a more > > friendly error message. > > > > > Well, my thinking is that the recent patch to mountd that avoids > doing mount update for non-exported file systems + one that doesn't > allow automounted volumes to be exported fixes this bug: > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > That way, there is no rush w.r.t. how to update the high order > bits of flags. (As noted in the comment w.r.t. the review of D2506, > I'm not sure if an updated syscall is allowed to be MFC'd.) > Since MNT_AUTOMOUNTED is the only high order bit at this time, > once it is fixed, no MFC of the more generic fix is needed. > > Make sense? rick Yes. To sum this up: one approach of dealing with it would be to add a separate textual "flags" field (https://reviews.freebsd.org/D2506); another is extending the flags nmount(2) argument to uint64 (https://reviews.freebsd.org/D2524), and autors of both don't intend to bring either of them into the tree at this time, since the mountd problem was actually fixed earlier, by a simple mountd(8) change. To be honest, I wonder if we should just have an API to convert binary flags (as obtained from statfs) back to textual form (iov), and use that to ignore the 'flags' argument altogether and pass everything in textual form. Either way - let's leave it until it's actually needed.