Eric Schrock wrote:
On Mon, Sep 18, 2006 at 02:20:24PM -0400, Torrey McMahon wrote:
1 - ZFS is self consistent but if you take a LUN snapshot then any
transactions in flight might not be completed and the pool - Which you
need to snap in its entirety - might not be consistent. The more LUNs
you have in the pool the more problematic this could get. Exporting the
pool first would probably get around this issue.
This isn't true. The snapshot will be entirely consistent - you will
have just lost the last few seconds of non-synchronous writes.
When a synchronous write comes in does it wait for other pending i/o to
complete? Which writes are tagged as synchronous? (Checksums and
uberblocks?)
If you take a snapshot of the different devices in a pool without using
a transaction group of some kind you could still be out of whack but
that would be a bad idea in the first place.
2 - If you import LUNs with the same label or ID as a currently mounted
pool then ZFS will .... no one seems to know. For example: I have a pool
on two LUNS X and Y called mypool. I take a snapshot of LUN X & Y,
ignoring issue #1 above for now, to LUN X' and LUN Y' and wait a few
days. I then present LUNs X' and Y' to the host. What happens? Make it
even more complex and present all the LUNs to the host after a reboot.
Do you get different parts of the pool from different LUNs? Does ZFS
say, "What the hell?!??!"
ZFS will not allow you to import the second pool (I believe it won't
even present the pool as a valid option to import). Each pool is
identified by a unique GUID. You cannot have two pools active on the
system with the same GUID. If this is really a valid use case, we could
invent a way to assign a new GUID on import.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
