From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 19 21:53:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9675B420; Tue, 19 Nov 2013 21:53:38 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 590F12FAD; Tue, 19 Nov 2013 21:53:38 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 08160359316; Tue, 19 Nov 2013 22:53:35 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id F1085CB4E; Tue, 19 Nov 2013 22:53:34 +0100 (CET) Date: Tue, 19 Nov 2013 22:53:34 +0100 From: Jilles Tjoelker To: Doug Ambrisko Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20131119215334.GA30794@stack.nl> References: <51B3B59B.8050903@erdgeist.org> <201306101152.17966.jhb@freebsd.org> <52854161.6080104@FreeBSD.org> <20131115010854.GA76106@ambrisko.com> <20131116183129.GD59496@kib.kiev.ua> <20131118190142.GA28210@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131118190142.GA28210@ambrisko.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Dirk Engling , Jase Thew , mdf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 21:53:38 -0000 On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote: > On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote: > | I think that struct mount should have a const char * field where the > | non-trimmed path is stored and used for match at unmount. f_mntonname > | truncation would be only unfortunate user interface glitch. > Note that we are not storing the path in mount structure so no structures > have changed which is nice since then we haven't introduced any real > ABI breakage. So we could MFC this. The match isn't critical since > umount will fall back to fsid and work. One thing that might be good to > do is change umount to try to umount via fsid first and then do the > match if the fsid failed versus the other way round that it does now. > The problem I see is if someone tries to do things based on the parsed > output of mount/df then that will fail since the output is truncated. As noted in comments in sbin/umount/umount.c, the statfs() call is deliberately after the mount list checks because it may block forever for unresponsive NFS servers. It would be unfortunate if hung NFS filesystems would have to be forcibly unmounted by copy/pasting the fsid from 'mount -v'. I like the idea of allowing longer mount paths in a simple way, though. -- Jilles Tjoelker