From owner-freebsd-arm@freebsd.org Thu Aug 10 17:32:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3415FDD86F3 for ; Thu, 10 Aug 2017 17:32:03 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 A8AB46A896; Thu, 10 Aug 2017 17:32:02 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id o85so930542lff.1; Thu, 10 Aug 2017 10:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWInlbhySIMZUpxlKqYQpGdFtY68md5K5nQhRT9A6Eg=; b=S03EqsM1mfIrFeaZ4f6sB+kmnqtI3fL+OROsAOa+oGqLd3KWYTJzWOujGgzabN9H2a X+tnCde9qeRQmTAlZwjWPaEjeT4lS1ydbZQdrSJNMHIfDxIm8J5lwztoMa6/XyoCysEi i52Nwd8xv6Yu4b0wll/wTX3YGsuF/3hEG2/XioEkE4OJYNkqnC6gvHPwgx19tf/Y54Bo 47aKuEytLjhAQ2q6s4ZrQVWNA+KkIsfP0kyR4Cf/kInNpsv9hBIPxQwrs7G7EdkcdIjT 4O83Fp0yrO+n8tbo8zMNVp00vPiq3ExANLqAfovqkyl6EEbpfEwZQBG2pg6AGY6tcueh 3Vaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWInlbhySIMZUpxlKqYQpGdFtY68md5K5nQhRT9A6Eg=; b=jUOLff3lwHfQf6lbArCTnSqIsQIllpCH20PhXrLUWkave3PvKqK7eKdfK151S9/Y4S 8DU7FOhI6p0DnJO/+/EzNej9eY45TFhFk13uB3dJ01DOM7SqwgddXdSqfCJR7usbpLL1 8fE0cpxeDstBXehm822VHrI8K34kRJMipbWXB2sqatTJdvt8Kotv4Zmp/mwS9TExVNP0 8BzMLOkiPhpZrhgonX0OQo25TC1rjHPPeVU4A1LhlE8e8RTkdoXKlb33rUOb0cilVrYm W47BQtYr3T6Y32unf99NIvkSd0CWHjW7yzJ7JpruOWUybZrXoNO7v6mmtECC3WnmXbW6 Rznw== X-Gm-Message-State: AHYfb5hu0Ggx7tixnLp/tKXLw04oJeb+KCTuGyR0C++zHFzuIaMeUZqx BSuw4zGq1dl66wvX69s= X-Received: by 10.46.22.20 with SMTP id w20mr423664ljd.103.1502386320074; Thu, 10 Aug 2017 10:32:00 -0700 (PDT) Received: from [192.168.1.105] (c83-251-251-174.bredband.comhem.se. [83.251.251.174]) by smtp.gmail.com with ESMTPSA id g25sm1057250ljd.25.2017.08.10.10.31.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 10:31:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question on mountd From: Olavi Kumpulainen In-Reply-To: <1502380286.50720.97.camel@freebsd.org> Date: Thu, 10 Aug 2017 19:31:57 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4A19CA1E-C344-42AF-AAB2-E3095F2680A7@gmail.com> References: <1502380286.50720.97.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:32:03 -0000 Thanks Ian, Just a small follow up question - The reason to why -S works is that = mountd cannot interrupt the execution thread of a NFS request from a = client? Is this true in a multicore system as well? /Olavi > On 10 Aug 2017, at 17:51 , Ian Lepore wrote: >=20 > On Thu, 2017-08-10 at 16:56 +0200, Olavi Kumpulainen wrote: >> Hi guys, >>=20 >> I notice that mount SIGHUP=E2=80=99s mountd every time mount = succeeds. The >> SIGHUP causes mountd to remount all exported directories.If this >> happens while a NFS-client is accessing a share, an access error may >> occur. >> For this purpose, there is an option to mount, -S, which locks nfsd >> while the remount is executing. >>=20 >> Can anyone of you share why mount needs to SIGHUP mountd in the first >> place? It would make sense if mountd is restarted whenever >> /etc/exports is modified, but always seems like overkill. >>=20 >=20 > Based on looking through the mountd code a bit... When a new = filesystem > is mounted, it may be mounted on one of the mount points listed in > /etc/exports. If there was no fs mounted there previously, then = mountd > might have failed to set the in-kernel export attributes the last time > it processed the exports file, so it has to do the processing again > after the mount to update the in-kernel export data. It would be > really complex for mountd to try to figure out the minimal set of = "what > changed" after a mount succeeds, so it just completely reprocesses the > exports file, first removing all export data from the kernel, then re- > applying it all. >=20 > So, all in all, I think the right fix for this is to add > "mountd_flags=3D"-r -S" to your rc.conf file (-r is a default from > /etc/defaults/rc.conf). >=20 > -- Ian