On Jan 20, 2010, at 4:17 PM, Daniel Carosone wrote: > On Wed, Jan 20, 2010 at 03:20:20PM -0800, Richard Elling wrote: >> Though the ARC case, PSARC/2007/618 is "unpublished," I gather from >> googling and the source that L2ARC devices are considered auxiliary, >> in the same category as spares. If so, then it is perfectly reasonable to >> expect that it gets picked up regardless of the GUID. This also implies >> that it is shareable between pools until assigned. Brief testing confirms >> this behaviour. I learn something new every day :-) >> >> So, I suspect Lutz sees a race when both pools are imported onto one >> node. This still makes me nervous though... > > Yes. What if device reconfiguration renumbers my controllers, will > l2arc suddenly start trashing a data disk? The same problem used to > be a risk for swap, but less so now that we swap to named zvol.
This will not happen unless the labels are rewritten on your data disk, and if that occurs, all bets are off. > There's work afoot to make l2arc persistent across reboot, which > implies some organised storage structure on the device. Fixing this > shouldn't wait for that. Upon further review, the ruling on the field is confirmed ;-) The L2ARC is shared amongst pools just like the ARC. What is important is that at least one pool has a cache vdev. I suppose one could make the case that a new command is needed in addition to zpool and zfs (!) to manage such devices. But perhaps we can live with the oddity for a while? As such, for Lutz's configuration, I am now less nervous. If I understand correctly, you could add the cache vdev to rpool and forget about how it works with the shared pools. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
