zfs icon indicating copy to clipboard operation
zfs copied to clipboard

zvol links not updated correctly when containing dataset is renamed

Open KevinBuettner opened this issue 3 years ago • 3 comments

System information

Type Version/Name
Distribution Name Fedora
Distribution Version 35
Kernel Version 5.14.16-301.fc35.x86_64
Architecture x86_64
OpenZFS Version 2.1.1

Describe the problem you're observing

When using zfs rename, zvol links are not being updated correctly after the rename. Along the way, at least two other problems may be encountered too. See example below for details. I'll note in advance that the results you see may vary somewhat from the results that I show. I've run several of the trials shown below with differing results each time.

Describe how to reproduce the problem

0: The problem of missing / disappearing zvol links also occurs after shutting down a VM. (See #https://github.com/openzfs/zfs/issues/12712 .) It's serious enough that I've created a small script which resets (fixes) zvol links when I notice that they're messed up. I now run it (by hand) every time I shut down a VM. Here's an attachment with a gzip'd version of the script that I'm using to fix the zvol links:

fix-zvol-links.gz

I will use this script twice in the example below to fix the links prior to proceeding to the next step.

1: Set up variables for pool name and data set prefix:

[root@ocotillo ~]# POOL=puddle
[root@ocotillo ~]# DSP=rename-test

2: Create dataset

[root@ocotillo ~]# zfs create $POOL/$DSP-1

3: Create zvols and partition them, giving them two partitions each:

[root@ocotillo ~]# for d in D{1..8}; do zfs create -V 100MiB $POOL/$DSP-1/$d; D=/dev/zvol/$POOL/$DSP-1/$d; echo $D; sgdisk -Z -n1:1M:+49M -n2:0:0 $D; done
/dev/zvol/puddle/rename-test-1/D1
Creating new GPT entries in memory.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
The operation has completed successfully.
/dev/zvol/puddle/rename-test-1/D2
...

4: Examine /dev/zvol/$POOL/$DSP-1:

[root@ocotillo ~]# cd /dev/zvol/$POOL
[root@ocotillo puddle]# ls -l $DSP-1
total 0
lrwxrwxrwx 1 root root 14 Nov 14 21:32 D1 -> ../../../zd640
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D1-part1 -> ../../../zd640p1
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D1-part2 -> ../../../zd640p2
lrwxrwxrwx 1 root root 14 Nov 14 21:32 D2 -> ../../../zd656
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D2-part1 -> ../../../zd656p1
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D2-part2 -> ../../../zd656p2
lrwxrwxrwx 1 root root 14 Nov 14 21:32 D3 -> ../../../zd672
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D3-part1 -> ../../../zd672p1
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D3-part2 -> ../../../zd672p2
lrwxrwxrwx 1 root root 14 Nov 14 21:32 D4 -> ../../../zd688
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D4-part1 -> ../../../zd688p1
lrwxrwxrwx 1 root root 16 Nov 14 21:32 D4-part2 -> ../../../zd688p2
lrwxrwxrwx 1 root root 14 Nov 14 21:33 D5 -> ../../../zd704
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D5-part1 -> ../../../zd704p1
lrwxrwxrwx 1 root root 14 Nov 14 21:33 D6 -> ../../../zd720
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D6-part1 -> ../../../zd720p1
lrwxrwxrwx 1 root root 14 Nov 14 21:33 D7 -> ../../../zd736
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D7-part1 -> ../../../zd736p1
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D7-part2 -> ../../../zd736p2
lrwxrwxrwx 1 root root 14 Nov 14 21:33 D8 -> ../../../zd752
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D8-part1 -> ../../../zd752p1
lrwxrwxrwx 1 root root 16 Nov 14 21:33 D8-part2 -> ../../../zd752p2

Notice that links are missing for D5-part2 and D6-part2. This is another (perhaps related) bug, but I'm going to include it here along with the zfs rename problem.

5: Use script fix-zvol-links to add those missing links and examine directory again:

[root@ocotillo puddle]# fix-zvol-links > /dev/null
[root@ocotillo puddle]# ls -l $DSP-1
total 0
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D1 -> ../../../zd640
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D1-part1 -> ../../../zd640p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D1-part2 -> ../../../zd640p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D2 -> ../../../zd656
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D2-part1 -> ../../../zd656p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D2-part2 -> ../../../zd656p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D3 -> ../../../zd672
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D3-part1 -> ../../../zd672p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D3-part2 -> ../../../zd672p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D4 -> ../../../zd688
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D4-part1 -> ../../../zd688p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D4-part2 -> ../../../zd688p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D5 -> ../../../zd704
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D5-part1 -> ../../../zd704p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D5-part2 -> ../../../zd704p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D6 -> ../../../zd720
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D6-part1 -> ../../../zd720p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D6-part2 -> ../../../zd720p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D7 -> ../../../zd736
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D7-part1 -> ../../../zd736p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D7-part2 -> ../../../zd736p2
lrwxrwxrwx 1 root root 14 Nov 14 21:34 D8 -> ../../../zd752
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D8-part1 -> ../../../zd752p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D8-part2 -> ../../../zd752p2

Note that all links are now present.

6: Rename dataset containing the zvols / partitions that were created:

[root@ocotillo puddle]# zfs rename $POOL/$DSP-1 $POOL/$DSP-2

7: Examine directory, $DSP-2, in which we expect to see the various zvol / partition links:

[root@ocotillo puddle]# ls -l $DSP-2
total 0
lrwxrwxrwx 1 root root 14 Nov 14 21:36 D2 -> ../../../zd656
lrwxrwxrwx 1 root root 14 Nov 14 21:36 D8 -> ../../../zd752

Note that this directory is woefully underpopulated. This demonstrates the bug.

8: Examine directory, $DSP-1; the fact that this directory still exists is also a bug.

[root@ocotillo puddle]# ls -l $DSP-1
total 0
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D1-part1 -> ../../../zd640p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D1-part2 -> ../../../zd640p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D2-part1 -> ../../../zd656p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D2-part2 -> ../../../zd656p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D3-part1 -> ../../../zd672p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D3-part2 -> ../../../zd672p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D4-part1 -> ../../../zd688p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D4-part2 -> ../../../zd688p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D5-part1 -> ../../../zd704p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D5-part2 -> ../../../zd704p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D6-part1 -> ../../../zd720p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D6-part2 -> ../../../zd720p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D7-part1 -> ../../../zd736p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D7-part2 -> ../../../zd736p2
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D8-part1 -> ../../../zd752p1
lrwxrwxrwx 1 root root 16 Nov 14 21:34 D8-part2 -> ../../../zd752p2

Note that the partition links are still in $DSP-1. This is also a bug; these links should now be in $DSP-2.

9: Run workaround script fix-zvol-links again and observe correct link placement:

[root@ocotillo puddle]# fix-zvol-links > /dev/null
Error: Error opening /dev/zd736: Unknown error 512
[root@ocotillo puddle]# ls -l $DSP-1
ls: cannot access 'rename-test-1': No such file or directory

The fact that rename-test-1 no longer exists is good; that's what we should have seen in step 8, above. Continuing...

[root@ocotillo puddle]# ls -l $DSP-2
total 0
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D1 -> ../../../zd640
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D1-part1 -> ../../../zd640p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D1-part2 -> ../../../zd640p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D2 -> ../../../zd656
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D2-part1 -> ../../../zd656p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D2-part2 -> ../../../zd656p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D3 -> ../../../zd672
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D3-part1 -> ../../../zd672p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D3-part2 -> ../../../zd672p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D4 -> ../../../zd688
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D4-part1 -> ../../../zd688p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D4-part2 -> ../../../zd688p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D5 -> ../../../zd704
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D5-part1 -> ../../../zd704p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D5-part2 -> ../../../zd704p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D6 -> ../../../zd720
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D6-part1 -> ../../../zd720p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D6-part2 -> ../../../zd720p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D7 -> ../../../zd736
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D7-part1 -> ../../../zd736p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D7-part2 -> ../../../zd736p2
lrwxrwxrwx 1 root root 14 Nov 14 21:38 D8 -> ../../../zd752
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D8-part1 -> ../../../zd752p1
lrwxrwxrwx 1 root root 16 Nov 14 21:38 D8-part2 -> ../../../zd752p2

This is the output that we should have seen in step 7.

10: Clean up:

[root@ocotillo puddle]# zfs destroy -r $POOL/$DSP-2

KevinBuettner avatar Nov 15 '21 05:11 KevinBuettner

#12759 may make some of your dreams come true; if you have the capability, could you test a version with that PR, and see how much of this persists?

rincebrain avatar Nov 15 '21 05:11 rincebrain

That commit from https://github.com/openzfs/zfs/pull/12759 fixes two of the three problems that I reported. In particular, all links are present after creating the zvols and partitioning them. Also, after the rename, all of the D1..D8 links are present in /dev/zvol/$POOL/$DSP-2.

However, all of the D{1..8}-part{1,2} links are still present in /dev/zvol/$POOL/$DSP-1. I think this is a different bug from the one that's being fixed by https://github.com/openzfs/zfs/pull/12759.

KevinBuettner avatar Nov 24 '21 22:11 KevinBuettner

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Nov 26 '22 21:11 stale[bot]