From owner-freebsd-fs@FreeBSD.ORG Wed Dec 15 19:16:16 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 C11DB106566B; Wed, 15 Dec 2010 19:16:16 +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 3F06B8FC13; Wed, 15 Dec 2010 19:16:16 +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 oBFJFw6s035888; Wed, 15 Dec 2010 20:16:14 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBFJFwPP035887; Wed, 15 Dec 2010 20:15:58 +0100 (CET) (envelope-from olli) Date: Wed, 15 Dec 2010 20:15:58 +0100 (CET) Message-Id: <201012151915.oBFJFwPP035887@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, arundel@FreeBSD.ORG In-Reply-To: <20101214210839.GB81772@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]); Wed, 15 Dec 2010 20:16:14 +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: Wed, 15 Dec 2010 19:16:16 -0000 Alexander Best wrote: > Oliver Fromme wrote: > > 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? It's possible to do that, but it requires a complete rewrite of how options are parsed in the vfs code. Personally I don't think it's worth the trouble. Normally a user notices the problem quickly when he types "df" (as you did). The problem is that vfs_scanopt() uses vsscanf() which works similar to the userland function with the same name (though it's not identical). vsscanf() only returns the number of items successfully converted, which is 1 in this case. The problem is that the *scanf() API is rather stupid. The simplest solution might be to add a new flag to *scanf() indicating that unit suffixes (K, M, G, T) are allowed and parsed appropriately. But you still won't get a warning if there's an invalid suffix. A work-around would be to add %n to the conversion, which returns the number of characters consumed so far. If it's less than the total length of the string, then there is some trailing garbage, obviously. Another, possibly simpler way would be to add %c and check if the result is 2. Another problem is that the mount code in the kernel cannot return a warning to the mount(8) utility. It only returns success or failure and an errno code. So, the only thing you can do is print a kernel message that goes to the dmesg buffer and to the console (and probably some log file), but not necessarily to the terminal of the user who is executing the mount command. Best regards Oliver PS: From my signature collection: "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek -- 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 "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall