On 9/22/2010 11:15 AM, Markus Kovero wrote:
Such configuration was known to cause deadlocks. Even if it works now (which I
don't expect to be the case) it will make your data to be cached twice. The CPU
utilization> will also be much higher, etc.
All in all I strongly recommend against such setup.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
p...@freebsd.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
Well, CPU utilization can be tuned downwards by disabling checksums in inner
pools as checksumming is done in main pool. I'd be interested in bug id's for
deadlock issues and everything related. Caching twice is not an issue,
prefetching could be and it can be disabled
I don't understand what makes it difficult for zfs to handle this kind of
setup. Main pool (testpool) should just allow any writes/reads to/from volume,
not caring what they are, where as anotherpool would just work as any other
pool consisting of any other devices.
This is quite similar setup to iscsi-replicated mirror pool, where you have
redundant pool created from iscsi volumes locally and remotely.
Yours
Markus Kovero
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.
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.
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.
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
