Project

General

Profile

Bug #8942

zfs promote .../%recv should be an error

Added by Ezomori Nozomu over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Low
Category:
zfs - Zettabyte File System
Start date:
2017-12-28
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:

Description

Reported on the ZFSonLinux github repo https://github.com/zfsonlinux/zfs/issues/4843, fixed by https://github.com/zfsonlinux/zfs/pull/6339:

If we are in the middle of an incremental zfs receive, the child .../%recv will exist. If you concurrently run zfs promote .../%recv, it will "work", but then zfs gets confused. For example, there's no obvious way to destroy the containing filesystem (because it is now a clone of its invisible child).

Attempting to do this promote should be an error. We could fix this by having zfs_ioc_promote() check if zc_name contains a %, similar to zfs_ioc_rename().

root@openindiana:~# POOLNAME='testpool'
root@openindiana:~# TMPDIR='/tmp'
root@openindiana:~# zpool destroy -f $POOLNAME
root@openindiana:~# rm -f $TMPDIR/zpool_$POOLNAME.dat
root@openindiana:~# mkfile 128m $TMPDIR/zpool.dat
root@openindiana:~# zpool create -O mountpoint=$TMPDIR/$POOLNAME $POOLNAME $TMPDIR/zpool.dat
root@openindiana:~# zfs create -o mountpoint=$TMPDIR/$POOLNAME/src $POOLNAME/src 
root@openindiana:~# dd if=/dev/urandom of=/$TMPDIR/$POOLNAME/src/file.dat bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 1.332270 secs (7870596 bytes/sec)
root@openindiana:~# zfs snap $POOLNAME/src@snap1
root@openindiana:~# dd if=/dev/urandom of=/$TMPDIR/$POOLNAME/src/file.dat bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 1.186960 secs (8834133 bytes/sec)
root@openindiana:~# zfs snap $POOLNAME/src@snap2
root@openindiana:~# dd if=/dev/urandom of=/$TMPDIR/$POOLNAME/src/file.dat bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 4.167742 secs (2515933 bytes/sec)
root@openindiana:~# zfs snap $POOLNAME/src@snap3
root@openindiana:~# zfs send -p $POOLNAME/src@snap1 | zfs recv -vu $POOLNAME/dst
receiving full stream of testpool/src@snap1 into testpool/dst@snap1
received 10.1MB stream in 2 seconds (5.04MB/sec)
root@openindiana:~# zfs send -pI $POOLNAME/src@snap1 $POOLNAME/src@snap3 | dd bs=1M count=15 | zfs recv -svu $POOLNAME/dst
0+15 records in
0+15 records out
7492 bytes transferred in 0.047300 secs (158394 bytes/sec)
receiving incremental stream of testpool/src@snap2 into testpool/dst@snap2
cannot receive incremental stream: checksum mismatch or incomplete stream.
Partially received snapshot is saved.
A resuming stream can be generated on the sending system by running:
    zfs send -t 1-d1172b276-e8-789c636064000310a501c49c50360710a715e5e7a69766a63040c124fbd9856f99765a2b00d9ec48eaf293b252934b207c10c0904f4b2b4e2d618003903c1b927c5265496a3103aa3cb2fe927c882b7c22ce963d29dbd4658024cf0996cf4bcc4d05d2a9c52505f9f939fac545c90ec57989054608330126352022
root@openindiana:~# zfs get name,inconsistent,mountpoint,origin $POOLNAME/dst/%recv
NAME                PROPERTY      VALUE                    SOURCE
testpool/dst/%recv  name          testpool/dst/%recv       -
testpool/dst/%recv  inconsistent  1                        -
testpool/dst/%recv  mountpoint    /tmp/testpool/src/%recv  inherited from testpool/dst
testpool/dst/%recv  origin        testpool/dst@snap1       -
root@openindiana:~# zfs promote $POOLNAME/dst/%recv
root@openindiana:~# 
root@openindiana:~# zfs destroy $POOLNAME/dst
cannot destroy 'testpool/dst': dataset already exists
root@openindiana:~# zfs destroy -r $POOLNAME/dst
cannot destroy 'testpool/dst': dataset already exists
root@openindiana:~# zfs destroy -rR $POOLNAME/dst
cannot destroy 'testpool/dst': dataset already exists
root@openindiana:~# 

History

#1

Updated by Electric Monk over 1 year ago

  • Status changed from New to Closed

git commit add927f8c8d101e16c23eb9cd270be4fd7edf7d5

commit  add927f8c8d101e16c23eb9cd270be4fd7edf7d5
Author: loli10K <ezomori.nozomu@gmail.com>
Date:   2018-02-08T05:16:39.000Z

    8942 zfs promote .../%recv should be an error
    Reviewed by: Paul Dagnelie <pcd@delphix.com>
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Also available in: Atom PDF