On 11/04/2013 08:42 AM, [email protected] wrote: > Hello, > > I have scenario for splitbrain in ZFSonLinux > > Create zpool (2 disks in mirror) > # zpool create lake mirror sdb sdc > > Create file1 > # dd if=/dev/urandom of=/lake/file1 bs=1M count=10 ; sync > > Remove disk sdb > > Create file2 > # dd if=/dev/urandom of=/lake/file2 bs=1M count=10 ; sync > > Hard power off. Connect sdb, and disconnect sdb. Power on. > > Create file3 > # dd if=/dev/urandom of=/lake/file3 bs=1M count=10 ; sync > > Hard power off. Connect sdc. Power on. > > # ls -la /lake > razem 20503 > drwxrwxrwx 2 nobody nogroup 4 lis 4 2013 . > drwxr-xr-x 10 root root 4096 paź 19 10:59 .. > -rw-r--r-- 1 nobody nogroup 10485760 lis 4 2013 file1 > -rw-r--r-- 1 nobody nogroup 10485760 lis 4 2013 file3 > > Result: raid resynced and file2 dissapeared. > > This scenario can be easly acheved > IE: > - cable of power sdb failure > - switch power cable sdb with sdc (for checking) > - connect two healthy power cables to all disks > > Do you have any solution to prevent this issue? > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. >
You would want to do a readonly import to avoid making changes whenever you have a situation where your pool is divided into two halves. That being said, there is the potential for bad things to happen should the two halves have the same latest transaction group commit number, yet have been updated independently. In your case, it seems that the side with the higher transaction commit won, but I do not think that the code is intended to handle this scenario. e.g. using the -T option to go to a common, yet different, transction id in the past might cause problems. This is an interesting corner case. I will CC the Open ZFS developer list so that others can add their thoughts.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
