Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 May 2011 00:30:53 +0200
From:      Per von Zweigbergk <pvz@itassistans.se>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: HAST + ZFS self healing? Hot spares?
Message-ID:  <4DD59A1D.7010406@itassistans.se>
In-Reply-To: <20110519170740.GA2100@garage.freebsd.pl>
References:  <85EC77D3-116E-43B0-BFF1-AE1BD71B5CE9@itassistans.se> <4DD37C69.5020005@digsys.bg> <4DD3855E.8020802@itassistans.se> <20110519170740.GA2100@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2011-05-19 19:07, Pawel Jakub Dawidek wrote:
> Having recursive ZFS pools is bad idea and most likely it was cause
> deadocks. You also pay all the costs with checksumming, ARC cache, etc.
> twice. Very bad idea.
I've considered this. Checksumming can be disabled in ZFS on the 
filesystem level (so I guess you could easily disable it for an entire 
pool). The ARC cannot be disabled on a filesystem or pool level though, 
as far as I can tell, only on the entire machine level, which seems like 
a bad idea.

Just the fact that there would be ARC duplication would be enough to 
make me seriously reconsider this.
>>> Some reported they used HAST for the SLOG as well. I do not know
>>> if using HAST for the L2ARC makes any sense. On failure you will
>>> import the pool on the slave node and this will wipe the L2ARC
>>> anyway.
>> Yes, running HAST on L2ARC doesn't make much sense, I'd have to run
>> HAST on the ZIL though if I opted for Variant 1 (which I don't think
>> I will).
> Using HAST for L2ARC devices might make no sense, but they are part of
> the pool. So if you import the pool on another machine L2ARC device will
> be failed. You may experiment with importing the pool, removing current
> L2ARC devices and attaching machine-local L2ARC devices. This way you
> avoid HAST for L2ARC, but not sure how reliable can that be.
The KISS way to solve this would be to simply add both of the local 
L2ARC devices. So no matter on which node you import it, you're going to 
get an L2ARC imported, and one of them in a failed status because it 
can't find it.

You'd have to live with the pool status being reported as degraded even 
though there is no problem though, which makes would make me inclined to 
simply script adding the L2ARC device when it is imported (and removing 
other cache devices), if that were the avenue I was pursuing.



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