Comment below. Perhaps someone from Sun's ZFS team can fill in the blanks, too.
On Jan 20, 2010, at 3:34 AM, Lutz Schumann wrote: > Actually I found some time (and reason) to test this. > > Environment: > - 1 osol server > - one SLES10 iSCSI Target > - two LUN's exported via iSCSi to the OSol server > > I did some rescilver tests to see how ZFS resilvers devices. > > Prep: > > osol: create a pool (myiscsi) with one mirror pair made from the two iSCSI > backend disks of SLES10 > > Test: > > osol: both disks ok, > osol: txn in ueberblock of pool = 86 > sles10: remove one disk (lun=1) > osol: disk is detected failed, pool degraded > osol: write with oflag=direct; sync multiple times to the pool > osol: create fs myiscsi/test > osol: txn in ueberblock = 107 > > osol: power off (hard) > sles10: add lun 1 again (the one with txn 86) > sles10: remove lun 0 (the onw with txn 107) > osol: power on > > osol: txn in ueberblock = 92 > osol: zfs myiscsi/test does not exist > osol: create fs myiscsi/mytest_old > osol: txn in ueberblock = 96 > > osol: power off (hard) > sles10: add lun 0 again (with txn 107) > sles10: both luns are there > > osol: Resilvering happens automatically > > osol: txn in ueberblock = 112 > osol: filesystem myiscsi/test exists > > ... same thing other way around to see if rescilver direction is persistent > ... > > osol: both disks ok, > osol: txn in ueberblock = 120 > sles10: remove one disk (lun=0) > osol: write with oflag=sync; sync multiple times > osol: create fs myiscsi/test > osol: txn in ueberblock = 142 > > osol: power off (hard) > sles10: add lun 0 again (the one with txn 120) > sles10: remove lun 1 (the onw with txn 142) > osol: boot > > osol: txn in ueberblock = 127 > osol: filesystem myiscsi/test does not exist > osol: create fs myiscsi/mytest_old > osol: txn in ueberblock = 133 > osol: power off > > sles10: add lun 1 again (with txn 142) > sles10: both luns are there > > osol: boot > > osol: Resilvering happens automatically > > osol: txn in ueberblock = 148 > osol: filesystem myiscsi/test exists > > --- > > From this tests it seems that the latest txn always wins. Yes, this is by design. txg IDs are expected to be monotonically increasing. The largest txg ID corresponds to the latest txg. > This practially means that the jbod with most changes (in terms of > transacitons) will always sync over the one with the least modifications. > > Could someone confirm this assumtion ? > > Could someone explain resilvering direction selection ? > > Regards, > Robert > > > p.s. I did not test split brain, but this is next. (The planned setup is > clustered not iSCSI but SAS, so the split brain is more academic in this > case). Split brain is a cluster feature and the most common methods of handling split brain do not occur at the file system level. Could you share your test plan? -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
