From owner-freebsd-fs@FreeBSD.ORG Tue Dec 14 21:08:39 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 3071E1065670; Tue, 14 Dec 2010 21:08:39 +0000 (UTC) Date: Tue, 14 Dec 2010 21:08:39 +0000 From: Alexander Best To: freebsd-fs@FreeBSD.ORG Message-ID: <20101214210839.GB81772@freebsd.org> References: <20101211193433.GA18970@freebsd.org> <201012131819.oBDIJs1C008825@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201012131819.oBDIJs1C008825@lurza.secnetix.de> 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 List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 21:08:39 -0000 On Mon Dec 13 10, Oliver Fromme wrote: > 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). i see. since the "m" gets ignored there's no chance of detecting a value that doesn't comply to the "%qu" format? and maybe issuing a warning that the size value was invalid? adding extra code which resembles expand_number() seems overkill in this case imo. cheers. alex > > 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 -- a13x