On Thu, Jan 21, 2010 at 09:36:06AM -0800, Richard Elling wrote: > 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.
It occurred to me later yesterday, while offline, that the pool in question might have autoreplace=on set. If that were true, it would explain why a disk in the same controller slot was overwritten and used. Lutz, is the pool autoreplace property on? If so, "god help us all" is no longer quite so necessary. > > 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. Wait, huh? That's a totally separate issue from what I understood from the discussion. What I was worried about was that disk Y, that happened to have the same cLtMdN address as disk X on another node, was overwritten and trashed on import to become l2arc. Maybe I missed some other detail in the thread and reached the wrong conclusion? > 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. The fact that l2arc devices could be caching data from any pool in the system is .. a whole different set of (mostly performance) wrinkles. For example, if I have a pool of very slow disks (usb or remote iscsi), and a pool of faster disks, and l2arc for the slow pool on the same faster disks, it's pointless having the faster pool using l2arc on the same disks or even the same type of disks. I'd need to set the secondarycache properties of one pool according to the configuration of another. > 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? This part, I expect, will be resolved or clarified as part of the l2arc persistence work, since then their attachment to specific pools will need to be clear and explicit. Perhaps the answer is that the cache devices become their own pool (since they're going to need filesystem-like structured storage anyway). The actual cache could be a zvol (or new object type) within that pool, and then (if necessary) an association is made between normal pools and the cache (especially if I have multiple of them). No new top-level commands needed. -- Dan.
pgp0MK26F4Jvy.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
