> 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.
It would be easy to check the timestamp as well as the transaction number.. Since they couldn't have been created at the same time, this will catch the rare corner case. It could also be extended to check all available uberblocks for consistency on mount. It won't catch the pool coming up with the other device missing, but that can only be done with a third location to store some information. Niels _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
