haasn
commented
8 years ago Note: I don't need to involve a second zpool at all; I get the same error when transferring to the same pool.
I also found out that not all of my datasets are affected, I just happened to get unlucky when I tested a few at random. I'm still not sure what distinguishes the ones that are from the ones that aren't affected, but I have a feeling it may perhaps be related to xattrs, ACLs, paxmarks, SELinux contexts or something of that nature, because it only seems to affect sufficiently nontrivial datasets. (I have feature@large_dnode enabled, acltype=posixacl and xattr=sa)
That said, if I try reproducing it by copying over /usr/bin/sudo and /bin/ping into the ‘test’ dataset and paxmarking them, and it still works fine. (And I no longer have a SELinux kernel or related userland installed)
I've also tried dumping 1G of /dev/urandom into the ‘test’ dataset, and it still transmits fine. I'm really not sure what else I should be trying to try and reproduce it on a clean dataset. I can't find a pattern among the ones that are affected - they're both small and large and contain all sorts of different files, yet some seem to get sent correctly where others fail.
Edit: Turns out that actually, some of the datasets which failed to get received on a different pool actually work fine on the same pool - although some fail even on the same pool. It also seems like there's a difference between -R and non--R here, some fail with -R but works without it, which is contrast to the behavior I saw in my first post where it failed even without -R - although that may have been because I was testing on one of the datasets that always seems to fail in my tests (zarathustra/ROOT/gentoo).
I'm suffering from a combinatorial explosion of variables and different cases here, and I'm struggling to even document what I'm observing. I'll continue trying to reproduce the issue on a clean dataset when I get the time/energy.
loli10K
angstymeat
I have tried a number of different invocations and permutations of the following yet the result is always the same:
(Note:
backupwas mounted with altroot=/mnt/backup, but omitting that parmeter when importing does not help)I can try sending them one at a time instead of using -R:
I can try sending the
--head--filesystem directly, but this fails becausezarathustra/ROOT/gentoois in use.I can try many other invocations: (I'll omit the output, but the error is always the exact same)
I have gone through all of the
zpoolfeatures and double-checked that the zpool configuration is the same for both pools, as well as the creation-time properties on the root dataset.I can try sending other datasets, but every dataset that contains actual files fail, while the non-mountable datasets (like
zarathustra/ROOTwork fine):(These all fail with similar errors, differng only in the name)
However, confusingly, I can make a new dataset and send it just fine:
I don't really understand what's going on here. I can copy/paste invocations from guides and they simply fail to work on my end.
Versions tested:
I don't know how to create a minimal reproducer, since I can't even reproduce it myself except on the datasets I already have (for whatever reason).
zpool statusshows no errors.