Date: Sun, 5 Sep 2010 13:31:19 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org, jhell <jhell@DataIX.net> Subject: Re: zfs very poor performance compared to ufs due to lack of cache? Message-ID: <20100905203119.GA55546@icarus.home.lan> In-Reply-To: <06B9D23F202D4DB88D69B7C4507986B7@multiplay.co.uk> References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk> <AANLkTi=6bta-Obrh2ejLCHENEbhV5stbMsvfek3Ki4ba@mail.gmail.com> <4C825D65.3040004@DataIX.net> <7EA7AD058C0143B2BF2471CC121C1687@multiplay.co.uk> <1F64110BFBD5468B8B26879A9D8C94EF@multiplay.co.uk> <4C83A214.1080204@DataIX.net> <06B9D23F202D4DB88D69B7C4507986B7@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 05, 2010 at 09:13:16PM +0100, Steven Hartland wrote:
> ----- Original Message ----- From: "jhell" <jhell@DataIX.net>
>
> >I am not exactly sure what your source is right now but guessing its at
> >least 8.1-RELEASE & hoping its 8.1-STABLE.
> >
> >Line 3656 & 3657 of arc.c ? what are they ?
> >
> >Do they look like the following,
> >3656: uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count
> >3657: + cnt.v_cache_count);
>
> Sorry yes running 8.1-RELEASE with the patches mentioned atm:
>
> 3656 of arc.c looks like:
>
> if (arc_size > arc_c_min) {
> uint64_t evictable_memory =
> arc_mru->arcs_lsize[ARC_BUFC_DATA] +
> arc_mru->arcs_lsize[ARC_BUFC_METADATA] +
> arc_mfu->arcs_lsize[ARC_BUFC_DATA] +
> arc_mfu->arcs_lsize[ARC_BUFC_METADATA];
> available_memory += MIN(evictable_memory, arc_size - arc_c_min);
> }
>
> earlier at 3614 I have what I think your after which is:
> uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count);
No, that line of code is different than the one jhell provided.
Additionally, there are other changes in the same commit which are being
overlooked.
There have been changes between 8.1-RELEASE and RELENG_8 (8.0-STABLE),
some affecting ARC behaviour. Rather than go through "patch hell",
staring at hundreds of lines of code and trying to work out what got
changed where or hacking up a solution, I'd recommend you simply move to
RELENG_8 (8.1-STABLE) and see if the behaviour you describe goes away.
If it doesn't improve, patches might be written that address the
problem, and those patches will only be for RELENG_8, because that's
where all the attention is being applied to. RELENG_8_x (8.x-RELEASE)
branches do not get this attention (and this is intentional).
There is no official resource/announcement regarding when changes in the
FreeBSD ZFS code changes, regardless of branch. Users are apparently
"expected" to follow commits/changes as they come in.
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100905203119.GA55546>