[Richard makes a hobby of confusing Dan :-)] more below.. On Jan 21, 2010, at 1:13 PM, Daniel Carosone wrote:
> 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. I think this is a different issue. But since the label in a cache device does not associate it with a pool, it is possible that any pool which expects a cache will find it. This seems to be as designed. >>> 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. Don't use slow devices for L2ARC. Secondarycache is a dataset property, not a pool property. You can definitely manage the primary and secondary cache policies for each dataset. >> 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. Since the ARC is shared amongst all pools, it makes sense to share L2ARC amongst all pools. > 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. I propose a best practice of adding the cache device to rpool and be happy. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
