From owner-freebsd-fs@FreeBSD.ORG Wed Jun 22 10:42:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56690106564A for ; Wed, 22 Jun 2011 10:42:52 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D13F28FC15 for ; Wed, 22 Jun 2011 10:42:51 +0000 (UTC) Received: by fxm11 with SMTP id 11so793710fxm.13 for ; Wed, 22 Jun 2011 03:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=6BcFyEl+lcSzZs5gOgEuEmqIoEH3MNlVucDmWOqt6gQ=; b=Qf3UdGZOuJEAwlFwi2swLZaaWBXr7xJGVZdqNDB5D82weh6i5369EtsPp3cUL0qQHw RBVJURUu0eUvsrYqg0colTrRPL7zR17Z/A2PaW7aJow5lCiea7XGaMG36QG62aGojMwo FxW2edS81HT8CrCFTz5xBrFFtCUrkS/HOQwdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TQG6vS48FRngwVZ3gDgB3wysgfF8+rHKNGzrl7VjGQM09NsAbBX/LIzVXvbSNR02JM UUX6nCoG92xTTBDV+D3QccJQmQ7IndvAsZqfiJBYAdvjEIHqS/pFbop+Pn/JGUsCDDGx VtHuJjJFfBJjW+qsrDaAX+/Xtnhvwy9SEhy6o= Received: by 10.223.77.92 with SMTP id f28mr645139fak.37.1308737619429; Wed, 22 Jun 2011 03:13:39 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id q14sm225546faa.27.2011.06.22.03.13.37 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 03:13:38 -0700 (PDT) Date: Wed, 22 Jun 2011 13:13:28 +0300 From: Gleb Kurtsou To: Kostik Belousov Message-ID: <20110622101328.GA19866@tops> References: <20110621192147.GJ48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110621192147.GJ48734@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: bumping mount path lengths in struct statfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:42:52 -0000 On (21/06/2011 22:21), Kostik Belousov wrote: > On Tue, Jun 21, 2011 at 09:16:18AM -0600, Will Andrews wrote: > > Hi, > > > > struct statfs contains the following: > > > > 90 char f_mntfromname[MNAMELEN]; /* mounted filesystem */ > > 91 char f_mntonname[MNAMELEN]; /* directory on which mounted */ > > > > Where MNAMELEN is, currently, 88. These limit the length of the path > > that a filesystem can be mounted to. This is enforced by > > kern/vfs_mount.c:vfs_donmount(). This limit seems archaic, especially > > given use cases like virtualization (large filesystem structures to > > support underlying VMs), builds (which often make extensive use of > > chroot with nullfs/NFS), ZFS, snapshots, etc. Does anyone object to > > bumping MNAMELEN to 1024 (PATH_MAX/MAXPATHLEN)? Or some other > > reasonably large value? > > There is nothing inherently wrong with bumping the length. But the > work required is probably more then you estimated. The cause is the > ABI breakage. For sure, you will need to provide the shims for compat > syscalls. Unfortunately, this is not enough. > > Even quick look over our tree shows that struct statfs is used in API by > several base libraries. Look e.g. at the getmntinfo(3). Libc would need > shims too, at least. > > You will need to do the ABI analisys of the whole system, provide the > shims for the symbol-versioned libraries, and bump so version for > unversioned. I could do it as part of my 64-bit ino_t GSoC project. So should I change MNAMELEN to 1024? What about MFSNAMELEN, it's now 16. I think removing or increasing size of f_charspare field might also be a good idea. Thanks, Gleb.