Date: Wed, 11 May 2011 21:44:45 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org, Jason Hellenthal <jhell@DataIX.net> Subject: Re: ZFS: How to enable cache and logs. Message-ID: <alpine.GSO.2.01.1105112120220.20825@freddy.simplesystems.org> In-Reply-To: <20110512010433.GA48863@icarus.home.lan> References: <4DCA5620.1030203@dannysplace.net> <20110511100655.GA35129@icarus.home.lan> <4DCA66CF.7070608@digsys.bg> <20110511105117.GA36571@icarus.home.lan> <4DCA7056.20200@digsys.bg> <20110511120830.GA37515@icarus.home.lan> <20110511223849.GA65193@DataIX.net> <20110512010433.GA48863@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 May 2011, Jeremy Chadwick wrote: > > The "garbage collection" works when the SSD is idle. I have no idea > what "idle" actually means operationally, because again, vendors don't > disclose what the idle intervals are. 5 minutes? 24 hours? It > matters, but they don't tell us. (What confuses me about the "idle GC" > method is how it determines what it can erase -- if the OS didn't tell > it what it's using, how does it know it can erase the page?) Garbage collection is not necessarily just when the drive is idle. Regardless, if one "overwrites" a page (or part of a page), the drive can implement that by reading any non-overlapped existing content (which it already has to do), allocating a fresh (already erased) page, and then writing the composite to that new page. The "overwritten" page is then scheduled for erasure. This sort of garbage collector works by over-provisioning the actual amount of flash in the drive, which should be done anyway in a quality product. This simple recirculating/COW algorithm is a reason why TRIM is not really needed given sufficiently intelligent SSD design. > Therefore, simply put, users should be concerned when using ZFS on > FreeBSD with SSDs. It doesn't matter to me if you're only using > 64MBytes of a 40GB drive or if you're using the entire thing; no TRIM > means degraded performance over time. This seems unduely harsh. Even with TRIM, SSDs will suffer in continually write-heavy (e.g. server) environments. The reason is that the blocks still need to be erased and the erasure performance is limited. It is not uncommon for servers to be run close to their limits most of the time. One should not be ashamed with purchasing a larger SSD than the space consumption appears to warrant. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.01.1105112120220.20825>