Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cross-pool operation error handling inconsistent #2911

Closed
bprotopopov opened this issue Nov 19, 2014 · 1 comment
Closed

cross-pool operation error handling inconsistent #2911

bprotopopov opened this issue Nov 19, 2014 · 1 comment
Milestone
0.6.4

Comments

@bprotopopov
Copy link
Contributor

The following command reports 'internal error' and core dumps:

$ zfs clone pool1/ds1@s1 pool2/ds1-clone1

A closer look reveals that this ococurs because dsl_dir_hold() returns EINVAL instead of EXDEV when comparing pool names. There is also one other place dsl_rename_check() where ENXIO is returned instead of EXDEV. Correcting the error codes fixes the code dump/error return for the 'zfs clone' command and does not cause noticeable changes in behavior of 'zfs rename'.
@behlendorf behlendorf added this to the 0.6.4 milestone Nov 20, 2014
@behlendorf
Copy link
Contributor

Thanks! I see you've proposed a fix in #2912 we'll try to get that reviewed. It looks like illumos would suffer from the same problem.

kernelOfTruth pushed a commit to kernelOfTruth/zfs that referenced this issue Jul 10, 2015
@alhazred @kernelOfTruth
Illumos 5610 zfs clone from different source and target pools produce…
8024374 
…s coredump

Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>

References:
illumos/illumos-gate@03b1c29
https://www.illumos.org/issues/5610
https://www.illumos.org/issues/5824
openzfs#2911
openzfs@9063f65

Porting notes:
Remove the superfluous code, missing peaces from Illumos 5610, 5824

"remove those two checks for differing pools in dmu_objset_clone_check() that can never be true."

Ported-by: kernelOfTruth kerneloftruth@gmail.com
@kernelOfTruth kernelOfTruth mentioned this issue Jul 10, 2015
Closed
behlendorf pushed a commit to behlendorf/zfs that referenced this issue Jul 14, 2015
@alhazred @behlendorf
Illumos 5610 - zfs clone from different source and target pools produ…
1cddb8c 
…ces coredump

5610 zfs clone from different source and target pools produces coredump
Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>

References:
  illumos/illumos-gate@03b1c29
  https://www.illumos.org/issues/5610
  https://www.illumos.org/issues/5824
  openzfs#2911
  openzfs@9063f65

Ported-by: kernelOfTruth kerneloftruth@gmail.com
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#3584
janlam7 pushed a commit to janlam7/zfs that referenced this issue Jul 25, 2015
@alhazred
Illumos 5610 - zfs clone from different source and target pools produ…
ee33070 
…ces coredump

5610 zfs clone from different source and target pools produces coredump
Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>

References:
  illumos/illumos-gate@03b1c29
  https://www.illumos.org/issues/5610
  https://www.illumos.org/issues/5824
  openzfs#2911
  openzfs@9063f65

Ported-by: kernelOfTruth kerneloftruth@gmail.com
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#3584
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.4
Development

No branches or pull requests
2 participants
@behlendorf @bprotopopov