Date: Thu, 10 Mar 2005 17:12:14 +0000 From: Peter Edwards <peadar.edwards@gmail.com> To: Sergey Matveychuk <sem@freebsd.org> Cc: Mathieu Arnold <mat@mat.cc> Subject: Re: unionfs 5.4 Message-ID: <34cb7c84050310091243cdc342@mail.gmail.com> In-Reply-To: <423027B1.8080503@FreeBSD.org> References: <87is46kzk1.fsf@neva.vlink.ru> <41C26F23F7DF023CB3DF35C5@cc-171.int.t-online.fr> <20050305151903.GC26240@hub.freebsd.org> <87mzth18e2.fsf@neva.vlink.ru> <1DE178D508C1D70D1B5F9E87@cc-171.int.t-online.fr> <874qfpupk5.fsf@neva.vlink.ru> <DDE9BD25F957493B50EE49C5@cc-171.int.t-online.fr> <423027B1.8080503@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've found nullfs toooo slow in jail. There seems to be a common consensus that nullfs is a bit of a tortoise. Stab in the dark: I haven't looked at this in great detail, but the very top of nullfs_subr .c defines the size of a hashtables used for storing all the null nodes into. It's only 16 buckets. That seems awfully under provisioned to me: there might be tens of thousands of "underlying" vnodes, giving a best-case scenario of thousands of iterations over one of these buckets to find an upper "null" node. Even the hash function seems pretty ropey... unionfs has a similar hash table (32 buckets instead of 16, and separate locks on each bucket) but it might not invoke the searches as often: I'm not as familliar with its design. If someone experiencing these issues could try rebuilding after changing #define NNULLNODECACHE 16 to #define NNULLNODECACHE 1024 in null_subr.c (line 50 in my version, 1.45) And just see if it makes much of a difference. If so, it might be worth making more flexible. (Sizing proportionally to maxvnodes or something, as UFS does, or replacing with a more scalable data structure.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c84050310091243cdc342>