Date: Sun, 6 May 2012 10:43:21 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Simon <simon@optinet.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ZFS Kernel Panics with 32 and 64 bit versions of 8.3 and 9.0 Message-ID: <alpine.GSO.2.01.1205061034260.1678@freddy.simplesystems.org> In-Reply-To: <201205061521.q46FLML1011267@blade.simplesystems.org> References: <201205061521.q46FLML1011267@blade.simplesystems.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 May 2012, Simon wrote: > > So if you have a 50TB ZFS filesystem and your memory goes bad, even if ECC, > your entire 50TB is gonna go bunkers? disks fail, but memory doesn't? CPUs > don't fail? > > There are many things in a server that can fail and cause corruption, but that > shouldn't take down entire zpool. I'm okay with a few missing files ending up > in lost+found, but entire filesystem? That renders the entire thing useless if you > ask me. By your definition, computers would be useless. :-) There is no telling what might happen if a program (including kernel code) was to execute wrong instructions or read wrong data. This is not specific to zfs. Zfs caches large amounts of data in its in-memory ARC cache, which is succeptible to in-memory corruption. If it tried to detect and prevent memory corruption, it would be extremely slow and likely not work at all if there were actual failures. Part of the metadata structure of the pool needs to be cached in RAM for performance reasons. On the zfs-discuss list we sometimes hear of zfs checksum errors which are due to memory errors rather than disk errors. Zfs can be used without ECC memory, but pool reliability will suffer. 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.1205061034260.1678>