Date: Mon, 13 Dec 2010 19:19:54 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG, arundel@FreeBSD.ORG Subject: Re: expand_number(3) support for tmpfs -o size and -o maxfilesize Message-ID: <201012131819.oBDIJs1C008825@lurza.secnetix.de> In-Reply-To: <20101211193433.GA18970@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012131819.oBDIJs1C008825>