Date: Mon, 29 Sep 2008 23:12:16 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Andrew Snow <andrew@modulus.org> Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <20080930041215.GH86326@dan.emsphone.com> In-Reply-To: <48E183A2.8000209@modulus.org> References: <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> <48E183A2.8000209@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Sep 30), Andrew Snow said: > Zaphod Beeblebrox wrote: > > Also, there exists data within the ARC (I'm always tempted to say > > the ARC Cache, but that is redundant) that is also then in paging > > memory. > > OK, but one advantage of ZFS memory consumption is under heavy write > loads, where much of the memory is used to store and reorder writes. > The heavy memory consumption under reading is a shame, but ZFS has to > cache and use more metadata than UFS, so its a price you pay for the > extra features and benefits. > > What I think we need is a way to turn off read-caching except for > metadata. This allows ARC to only be used more efficiently. > Currently you can turn all read-ahead on or off, with the provided > sysctl tunables, but would be easy to implement a metadata-only > option. I found that access speed suffers when metadata is not > prefetched. That'd be handy, but at least on my system the data prefetcher isn't really called often enough to make a difference either way (assuming the counts are accurate). Metadata prefetch is a big win, however. (dan@dan.15) /home/dan> uptime 11:00PM up 5 days, 13:47, 21 users, load averages: 1.52, 1.68, 1.69 (dan@dan.15) /home/dan> sysctl kstat [..] kstat.zfs.misc.arcstats.hits: 211130907 (95%) kstat.zfs.misc.arcstats.misses: 9808431 kstat.zfs.misc.arcstats.demand_data_hits: 116614377 (98%) kstat.zfs.misc.arcstats.demand_data_misses: 2477943 kstat.zfs.misc.arcstats.demand_metadata_hits: 55805261 (96%) kstat.zfs.misc.arcstats.demand_metadata_misses: 2310006 kstat.zfs.misc.arcstats.prefetch_data_hits: 79878 (53%) kstat.zfs.misc.arcstats.prefetch_data_misses: 71741 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 38556033 (88%) kstat.zfs.misc.arcstats.prefetch_metadata_misses: 4947270 kstat.zfs.misc.arcstats.mru_hits: 23702582 (95%) kstat.zfs.misc.arcstats.mru_ghost_hits: 1274189 kstat.zfs.misc.arcstats.mfu_hits: 149722171 (98%) kstat.zfs.misc.arcstats.mfu_ghost_hits: 2944572 [..] kstat.zfs.misc.arcstats.p: 235221504 kstat.zfs.misc.arcstats.c: 268435456 kstat.zfs.misc.arcstats.c_min: 67108864 kstat.zfs.misc.arcstats.c_max: 268435456 kstat.zfs.misc.arcstats.size: 263926784 -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080930041215.GH86326>