Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Apr 2013 20:25:40 +0200
From:      mxb <mxb@alumni.chalmers.se>
To:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: ZFS: ZIL device export/import
Message-ID:  <2DE8AD5E-B84C-4D88-A242-EA30EA4A68FD@alumni.chalmers.se>
In-Reply-To: <op.wvhrfrhj8527sy@pinky>
References:  <5A2824CA-2A67-47FA-AB27-20C6EBD2C501@alumni.chalmers.se> <51699B8E.7050003@platinum.linux.pl> <BCBD7CDE-1BBB-4855-9240-897770FEF822@alumni.chalmers.se> <op.wvhrfrhj8527sy@pinky>

next in thread | previous in thread | raw e-mail | index | archive | help

On 13 apr 2013, at 20:10, "Ronald Klop" <ronald-freebsd8@klop.yi.org> =
wrote:

> The L2ARC is considered empty on startup/import. The ZIL might contain =
valuable data after a crash. So your setup is wrong. The ZIL is supposed =
to be one-on-one with the pool. You should move the ZILs to the JBOD. =
You can make a mirror of the ZIL devices to improve failsafe operation =
by redundancy.


I figured that out with mirror, thus my tests with slices - one slice on =
local SSD (per HU) the second half of the mirror on JBOD-slice =
(dedicated SSD there too). But this requires extra 'zpool online' and =
'zpool replace'.=20

As I understand there is no other way??
I'm forced to do those steps?

ZIL dev. on JBOD is a bit odd - the idea with local (per HU) ZIL is to =
postpone transfer of the data over SAS Expander.
Or at least buffer and then move over SAS Exp. .

//mxb=20=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2DE8AD5E-B84C-4D88-A242-EA30EA4A68FD>