On Thu, Jan 21, 2010 at 03:33:28PM -0800, Richard Elling wrote: > [Richard makes a hobby of confusing Dan :-)]
Heh. > > 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. I agree. For me, it was the main issue, and I still want clarity on it. However, at this point I'll go back to the start of the thread and look at what was actually reported again in more detail. > 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. Hm. My recollection was that node b's disk in that controller slot was totally unlabelled, but perhaps I'm misremembering.. as above. > > 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. Slow is entirely relative, as we discussed here just recently. They just need to be faster than the pool devices I want to cache. The wrinkle here is that it's now clear they should be faster than the devices in all other pools as well (or I need to take special measures). Faster is better regardless, and suitable l2arc ssd's are "cheap enough" now. It's mostly academic that, previously, faster/local hard disks were "fast enough", since now you can have both. > Secondarycache is a dataset property, not a pool property. You can > definitely manage the primary and secondary cache policies for each > dataset. Yeah, properties of the root fs and of the pool are easily conflated. > >> 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. Of course it does - apart from the wrinkles we now know we need to watch out for. > > 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. It is *still* not that simple. Forget my slow disks caching an even slower pool (which is still fast enough for my needs, thanks to the cache and zil). Consider a server config thus: - two MLC SSDs (x25-M, OCZ Vertex, whatever) - SSDs partitioned in two, mirrored rpool & 2x l2arc - a bunch of disks for a data pool This is a likely/common configuration, commodity systems being limited mostly by number of sata ports. I'd even go so far as to propose it as another best practice, for those circumstances. Now, why would I waste l2arc space, bandwidth, and wear cycles to cache rpool to the same ssd's that would be read on a miss anyway? So, there's at least one more step required for happiness: # zfs set secondarycache=none rpool (plus relying on property inheritance through the rest of rpool) -- Dan.
pgph2OAJgbY6C.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
