From owner-freebsd-fs@FreeBSD.ORG Fri May 18 13:10:18 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F4D816A401 for ; Fri, 18 May 2007 13:10:18 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 13BBF13C46A for ; Fri, 18 May 2007 13:10:17 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.centtech.com (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.8/8.13.8) with ESMTP id l4IDAFWH011030; Fri, 18 May 2007 08:10:16 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <464DA5B7.1000908@freebsd.org> Date: Fri, 18 May 2007 08:10:15 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.0 (X11/20070420) MIME-Version: 1.0 To: Howard Su References: <464C3DA7.3020003@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3267/Thu May 17 15:40:58 2007 on mh2.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh2.centtech.com Cc: fs@freebsd.org Subject: Re: size limit for TMPFS 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: Fri, 18 May 2007 13:10:18 -0000 On 05/18/07 01:28, Howard Su wrote: > On 5/17/07, Eric Anderson wrote: >> Track the memory usage on your own? As you allocate, keep a counter and > This is doable. The down site for this is we need another mutex to > protect this resource usage. This mutex will result performance issue. > because this mutex is per mount point. and when alloc/read a node, a > directory. From a quick glance, you are storing your inode count in the mount structure of the tmpfs. So, anytime you do anything with the fs, you have to lock the mount struct anyway, so there's no additional mutex when updating the block count vs inode count, right? Please correct me if I'm wrong here, since I'm still learning much about locking/vfs/etc. >> total up the usage outside of uma. (3) sounds good, except it may not >> be accurate, and that could lead to confusion for someone. > Can we state, the tmpfs size only limit to the file size. Meta data > will not be counted. Meta data limit will be adjusted by the kernel > resource or explicitly specified by the user. Seems reasonable, and if it's documented in the man page, it should reduce any confusion. Eric