Date: Fri, 18 May 2007 08:10:15 -0500 From: Eric Anderson <anderson@freebsd.org> To: Howard Su <howard0su@gmail.com> Cc: fs@freebsd.org Subject: Re: size limit for TMPFS Message-ID: <464DA5B7.1000908@freebsd.org> In-Reply-To: <f126fae00705172328k6927fb67r3bd27731209b2661@mail.gmail.com> References: <f126fae00705170236t687a92des3f42415fd06d75b9@mail.gmail.com> <464C3DA7.3020003@freebsd.org> <f126fae00705172328k6927fb67r3bd27731209b2661@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/18/07 01:28, Howard Su wrote: > On 5/17/07, Eric Anderson <anderson@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?464DA5B7.1000908>