Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Apr 2013 22:51:10 +0200
From:      "Ronald Klop" <ronald-freebsd8@klop.yi.org>
To:        freebsd-fs@freebsd.org
Subject:   Re: ZFS: ZIL device export/import
Message-ID:  <op.wvhyvkzx8527sy@pinky>
In-Reply-To: <2DE8AD5E-B84C-4D88-A242-EA30EA4A68FD@alumni.chalmers.se>
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> <2DE8AD5E-B84C-4D88-A242-EA30EA4A68FD@alumni.chalmers.se>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Apr 2013 20:25:40 +0200, mxb <mxb@alumni.chalmers.se> wrote:

>
> 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'.
>
> 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

I thought the idea of ZIL is a fast buffer before the write to slow disk.  
Are you really sure the SAS expander is the bottleneck in the system  
instead of the disks?

Ronald.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.wvhyvkzx8527sy>