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.

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

zfs send -nP prints to stderr instead of stdout #6618

Closed
dsnet opened this issue Sep 8, 2017 · 0 comments · Fixed by #6623
Closed

zfs send -nP prints to stderr instead of stdout #6618

dsnet opened this issue Sep 8, 2017 · 0 comments · Fixed by #6623

Comments

@dsnet
Copy link

dsnet commented Sep 8, 2017

Type Version/Name
Distribution Name Ubuntu
Distribution Version 16.04.2
Linux Kernel 4.4.0-62-generic
Architecture x64
ZFS Version 0.7.0-12_g9df9692
SPL Version 0.7.0-50_g1ea8942

I ran the following:

$ TOKEN=1-e9340a591-e0-789c636064000310a501c49c50360710a715e5e7a69766a63040c1c1fd57d4f77fdb59a70064b323a9cb4fca4a4d2e61606081aac3904f4b2b4e2d01c9e831c2e4d990e4932a4b528b81f48dd3068cd8f497e4435c21d976aa246d9ae2470d24794eb07c5e626e2a904ecccb7628ce4b2c3062800300c2281ff2
$ sudo zfs send -nP -t $TOKEN > /dev/null
resume token contents:
nvlist version: 0
	fromguid = 0x7eb9f6bf27d4bfc1
	object = 0x4
	offset = 0x12e0000
	bytes = 0x130cbd8
	toguid = 0xf121966674ca8619
	toname = tank@snap2
incremental	tank/mirror@snap1	tank@snap2

Notice that the output is being redirected to stdout, yet you still see some printout? This is because -nP when using in conjunction with -t prints to stderr instead of stdout. This is inconsistent with other usages of zfs send -nP where it outputs to stdout.

This inconsistency makes it harder to script.
@loli10K loli10K self-assigned this Sep 8, 2017
@loli10K loli10K mentioned this issue Sep 9, 2017
Merged
13 tasks
behlendorf pushed a commit that referenced this issue Oct 10, 2017
@loli10K @behlendorf
Fix intra-pool resumable 'zfs send -t <token>'
aee1dd4 
Because resuming from a token requires "guid" -> "snapshot" mapping
we have to walk the whole dataset hierarchy to find the right snapshot
to send; when both source and destination exists, for an incremental
resumable stream, libzfs gets confused and picks up the wrong snapshot
to send from: this results in attempting to send

   "destination@snap1 -> source@snap2"

instead of

   "source@snap1 -> source@snap2"

which fails with a "Invalid cross-device link" error (EXDEV).

Fix this by adjusting the logic behind dataset traversal in
zfs_iter_children() to pick the right snapshot to send from.

Additionally update dry-run 'zfs send -t' to print its output to
stderr: this is consistent with other dry-run commands.

Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #6618
Closes #6619
Closes #6623
aerusso pushed a commit to aerusso/zfs that referenced this issue Oct 11, 2017
@loli10K @aerusso
Fix intra-pool resumable 'zfs send -t <token>'
01d712b 
Because resuming from a token requires "guid" -> "snapshot" mapping
we have to walk the whole dataset hierarchy to find the right snapshot
to send; when both source and destination exists, for an incremental
resumable stream, libzfs gets confused and picks up the wrong snapshot
to send from: this results in attempting to send

   "destination@snap1 -> source@snap2"

instead of

   "source@snap1 -> source@snap2"

which fails with a "Invalid cross-device link" error (EXDEV).

Fix this by adjusting the logic behind dataset traversal in
zfs_iter_children() to pick the right snapshot to send from.

Additionally update dry-run 'zfs send -t' to print its output to
stderr: this is consistent with other dry-run commands.

Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#6618
Closes openzfs#6619
Closes openzfs#6623
aerusso pushed a commit to aerusso/zfs that referenced this issue Oct 12, 2017
@loli10K @aerusso
Fix intra-pool resumable 'zfs send -t <token>'
a72c20b 
Because resuming from a token requires "guid" -> "snapshot" mapping
we have to walk the whole dataset hierarchy to find the right snapshot
to send; when both source and destination exists, for an incremental
resumable stream, libzfs gets confused and picks up the wrong snapshot
to send from: this results in attempting to send

   "destination@snap1 -> source@snap2"

instead of

   "source@snap1 -> source@snap2"

which fails with a "Invalid cross-device link" error (EXDEV).

Fix this by adjusting the logic behind dataset traversal in
zfs_iter_children() to pick the right snapshot to send from.

Additionally update dry-run 'zfs send -t' to print its output to
stderr: this is consistent with other dry-run commands.

Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#6618
Closes openzfs#6619
Closes openzfs#6623
tonyhutter pushed a commit that referenced this issue Oct 16, 2017
@loli10K @tonyhutter
Fix intra-pool resumable 'zfs send -t <token>'
926c6ec 
Because resuming from a token requires "guid" -> "snapshot" mapping
we have to walk the whole dataset hierarchy to find the right snapshot
to send; when both source and destination exists, for an incremental
resumable stream, libzfs gets confused and picks up the wrong snapshot
to send from: this results in attempting to send

   "destination@snap1 -> source@snap2"

instead of

   "source@snap1 -> source@snap2"

which fails with a "Invalid cross-device link" error (EXDEV).

Fix this by adjusting the logic behind dataset traversal in
zfs_iter_children() to pick the right snapshot to send from.

Additionally update dry-run 'zfs send -t' to print its output to
stderr: this is consistent with other dry-run commands.

Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #6618
Closes #6619
Closes #6623
FransUrbo pushed a commit to FransUrbo/zfs that referenced this issue Apr 28, 2019
@loli10K @FransUrbo
Fix intra-pool resumable 'zfs send -t <token>'
3e45892 
Because resuming from a token requires "guid" -> "snapshot" mapping
we have to walk the whole dataset hierarchy to find the right snapshot
to send; when both source and destination exists, for an incremental
resumable stream, libzfs gets confused and picks up the wrong snapshot
to send from: this results in attempting to send

   "destination@snap1 -> source@snap2"

instead of

   "source@snap1 -> source@snap2"

which fails with a "Invalid cross-device link" error (EXDEV).

Fix this by adjusting the logic behind dataset traversal in
zfs_iter_children() to pick the right snapshot to send from.

Additionally update dry-run 'zfs send -t' to print its output to
stderr: this is consistent with other dry-run commands.

Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#6618
Closes openzfs#6619
Closes openzfs#6623
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
No milestone
Development

Successfully merging a pull request may close this issue.

Fix dryrun and intra-pool resumable 'zfs send' loli10K/zfs
2 participants
@loli10K @dsnet