> Actually, the mechanics of local pools inside pools is significantly > different than using remote volumes (potentially exported ZFS volumes) > to build a local pool from.
I don't see how, I'm referring to method where hostA shares local iscsi volume to hostB where volume is being mirrored with zfs to its local volume that is shared through iscsi, resulting sync mirrored pool. > And, no, you WOULDN'T want to turn off the "inside" pool's checksums. > You're assuming that this would be taken care of by the outside pool, > but that's a faulty assumption, since the only way this would happen > would be if the pools somehow understood they were being nested, and > thus could "bypass" much of the caching and I/O infrastructure related > to the inner pool. Good point. Checksums it is then. > Cacheing is also a huge issue, since ZFS isn't known for being > memory-slim, and as caching is done (currently) on a per-pool level, > nested pools will consume significantly more RAM. Without caching the > inner pool, performance is going to suck (even if some blocks are cached > in the outer pool, that pool has no way to do look-ahead, nor other > actions). The nature of delayed writes can also wreck havoc with caching > at both pool levels. Well, again, I don't see how nested pool would consume more RAM than invidual another pool created from dedicated disks. Read caching takes place twice, but I don't see it much of as problem nowadays, just double the ram. (ofcourse, depending on workload) look-ahead (prefetch?) hasn't work very well anyway so it's gong to be disabled, cache hit isn't great (worth it) on any workload. Also, write caching needs to be benchmarked, but I'd say, if it works like it should, there is no issues there, have to test it out thoroughly though. > Stupid filesystems have no issues with nesting, as they're not doing > anything besides (essentially) direct I/O to the underlying devices. UFS > doesn't have its own I/O subsystem, nor do things like ext* or xfs. > However, I've yet to see any "modern" filesystem do well with nesting > itself - there's simply too much going on under the hood, and without > being "nested-aware" (i.e. specifically coding the filesystem to > understand when it's being nested), much of these backend optimizations > are a recipe for conflict . > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA Thanks for your thoughts, if issues are performance related, they can be dealt with to some extent, more I'm worrying if there is still deadlock issues or other general stability issues to consider, haven't found anything useful from bugtraq yet though. Yours Markus Kovero _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
