Date: Mon, 29 Sep 2008 11:09:45 -0400 From: "Zaphod Beeblebrox" <zbeeble@gmail.com> To: "Andrew Snow" <andrew@modulus.org> Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> In-Reply-To: <48E080C0.9070103@modulus.org> References: <20080921213426.GA13923@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 29, 2008 at 3:16 AM, Andrew Snow <andrew@modulus.org> wrote: > However, as a core general purpose filesystem, it seems to have flaws, not >> the least of which is a re-separation of file cache and memory cache. >> > > For me, this doesn't matter because ZFS is so much faster than UFS > overall. Even if you don't use any of its features, the latest version > does sequential I/O and heavy random I/O faster than UFS on the same > hardware for me. > > Cases where UFS is faster are proving to be the exception rather than > the rule. > > However, I cannot recommend its use until it is stable, which it > currently still is not, under very heavy load. I certainly can't agree with this. I don't think you're measuring the performance of the machine --- only measuring the performance of the filesystem. When ZFS is active, memory is committed in the kernel to ZFS. That memory is then no longer available for paging. 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. You end up having to tune the size of the ARC to your workload, which is how UN*X did it upto 1992 or so. If you choose the wrong size for the ARC, you end up with very poor performance. In particular, the ARC fights for space with the nvidia binary driver (which really does need _real_ memory). To have the driver work at all, I have to keep the ARC from growing too large --- which is at odds with filesystem perofrmance.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40809290809j58639df8ka65184151161cab6>