Date: Sun, 6 Jan 2008 23:33:08 +0100 From: "Ivan Voras" <ivoras@freebsd.org> To: "Scott Long" <scottl@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: ZFS honesty Message-ID: <9bbcef730801061433y381159aakf2ad51faffdca987@mail.gmail.com> In-Reply-To: <47814E20.70801@samsco.org> References: <fll63b$j1c$1@ger.gmane.org> <20080106141157.I105@fledge.watson.org> <flr0np$euj$2@ger.gmane.org> <47810DE3.3050106@FreeBSD.org> <flr3iq$of7$1@ger.gmane.org> <478119AB.8050906@FreeBSD.org> <47814160.4050401@samsco.org> <478148FD.20605@FreeBSD.org> <47814E20.70801@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/01/2008, Scott Long <scottl@samsco.org> wrote: > I guess what makes me mad about ZFS is that it's all-or-nothing; either > it works, or it crashes. It doesn't automatically recognize limits and > make adjustments or sacrifices when it reaches those limits, it just > crashes. Wanting multiple gigabytes of RAM for caching in order to > optimize performance is great, but crashing when it doesn't get those > multiple gigabytes of RAM is not so great, and it leaves a bad taste in > my mouth about ZFS in general. I agree with the sentiment. I don't know about its implementation, but surely some kind of backout could have be implemented? I'm just guessing here: maybe the problem is in M_NOWAIT - maybe there could be a M_NOWAIT_BUT_ALLOW_NULL that would be safe to use in non-sleepable code but could return NULL, which could be tested and the whole file system request postponed...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730801061433y381159aakf2ad51faffdca987>