Date: Tue, 20 Mar 2018 10:21:02 +0200 From: Toomas Soome <tsoome@me.com> To: Markus Wild <fbsd-lists@dudes.ch> Cc: freebsd-current@freebsd.org Subject: Re: ZFS i/o error in recent 12.0 Message-ID: <6680868D-F08A-4AF4-B68D-7E20ADBA67D4@me.com> In-Reply-To: <20180320085028.0b15ff40@mwoffice.virtualtec.office> References: <201803192300.w2JN04fx007127@kx.openedu.org> <20180320085028.0b15ff40@mwoffice.virtualtec.office>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 20 Mar 2018, at 09:50, Markus Wild <fbsd-lists@dudes.ch> wrote: >=20 > Hi there, >=20 >> I've been encountered suddenly death in ZFS full volume >> machine(r330434) about 10 days after installation[1]: >>=20 >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS of pool zroot >> gptzfsboot: failed to mount default pool zroot >>=20 >=20 >> 268847104 30978715648 4 freebsd-zfs (14T) >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 >=20 > I had faced the exact same issue on a HP Microserver G8 with 8TB disks = and a 16TB zpool on FreeBSD 11 about a year ago. > My conclusion was, that over time (and updating the kernel), the = blocks for that kernel file were reallocated to a > later spot on the disks, and that however the loader fetches those = blocks, it now failed doing so (perhaps a 2/4TB > limit/bug with the BIOS of that server? Unfortunately, there was no = UEFI support for it, don't know whether that > changed in the meantime). The pool was always importable fine with the = USB stick, the problem was only with the boot > loader. I worked around the problem stealing space from the swap = partitions on two disks to build a "zboot" pool, just > containing the /boot directory, having the boot loader load the kernel = from there, and then still mount the real root > pool to run the system off using loader-variables in loader.conf of = the boot pool. It's a hack, but it's working > fine since (the server is being used as a backup repository). This is = what I have in the "zboot" boot/loader.conf: >=20 > # zfs boot kludge due to buggy bios > vfs.root.mountfrom=3D"zfs:zroot/ROOT/fbsd11" >=20 >=20 > If you're facing the same problem, you might give this a shot? You = seem to have plenty of swap to canibalize as well;) >=20 please check with lsdev -v from loader OK prompt - do the reported = disk/partition sizes make sense. Another thing is, even if you do update = the current build, you want to make sure your installed boot blocks are = updated as well - otherwise you will have new binary in the /boot = directory, but it is not installed on boot block area=E2=80=A6 rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6680868D-F08A-4AF4-B68D-7E20ADBA67D4>