From owner-freebsd-fs@FreeBSD.ORG Mon Dec 13 18:20:12 2010 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 7EA17106566B; Mon, 13 Dec 2010 18:20:12 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id F204D8FC18; Mon, 13 Dec 2010 18:20:11 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBDIJs37008826; Mon, 13 Dec 2010 19:20:09 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBDIJs1C008825; Mon, 13 Dec 2010 19:19:54 +0100 (CET) (envelope-from olli) Date: Mon, 13 Dec 2010 19:19:54 +0100 (CET) Message-Id: <201012131819.oBDIJs1C008825@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, arundel@FreeBSD.ORG In-Reply-To: <20101211193433.GA18970@freebsd.org> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Mon, 13 Dec 2010 19:20:10 +0100 (CET) Cc: Subject: Re: expand_number(3) support for tmpfs -o size and -o maxfilesize X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, arundel@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 18:20:12 -0000 Alexander Best wrote: > is it possible to get support for something like this fstab entry? > > tmpfs /tmp tmpfs rw,mode=1777,size=500m 0 0 expand_number(3) is a libc function which is availbale to userland, but the size= argument is parsed by the kernel. We don't have something like expand_number() in the kernel. A few parts of the kernel have grown their own: getenv_quad() in kern/kern_environment.c gv_sizespec() in geom/vinum/geom_vinum_share.c > tmpfs doesn't seem to handle humanzied numbers that well. df -h reports: > > Filesystem Size Used Avail Capacity Mounted on > tmpfs 17G 12M 17G 0% /tmp That's expected behaviour ... The function vfs_scanopt() is used to parse the size argument using the "%qu" format, expecting the number in bytes. So if you write "500m", it stops at the "m" and simply parses the number as 500 bytes, which is below the minimum size (4 KB), so it falls back to the default maximum size which is the total amount of memory available (RAM + swap). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless