expand_number(3) support for tmpfs -o size and -o maxfilesize
arundel at freebsd.org
Tue Dec 14 21:08:39 UTC 2010
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
> Best regards
> 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
More information about the freebsd-fs