On Tue, 2 Mar 2010, Brian Kolaci wrote:
So if there is corruption, can it be safely isolated so as to not
affect other datasets or LDoms? Or would it be likely to take down
the whole pool?
It seems like you are asking if there could be a software bug or a
firmware/hardware bug in the SAN. It is always possible for there to
be a bug. The bug might inflict the host system even if it uses many
smaller pools and the bug might not even be related to zfs.
From an administrative and performance standpoint it seems like the
large pool is better.
I think that a larger shared pool will be more satisfying and less
wasteful of resources. However, a large pool written to a single
This is what I had written in my document too. But all the SAN LUNs
are only 33GB (yes, even when they need over a TB there are lots of
33GB LUNs pooled). They're trying to get very efficient with
storage, which is why I started down this path. But I'm also trying
to measure the risk, if any, for moving to a larger pool rather than
a bunch of smaller per-virtual-host pools. Regardless of the
approach, the LUNs are all 33GB and thats the granularity of all
allocations.
The large pool will surely be more efficient with storage since it is
unlikely that all consumers will want/need to consume all of the space
pre-allocated for them. In fact, if there was an expected
per-consumer average of less than 50% consumption, you could use the
large pool with mirroring and still have enough space. :-)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
