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

Fix import can't find spare/l2cache when path change #6158

Closed
wants to merge 2 commits into from

Conversation

tuxoko
Copy link
Contributor

@tuxoko tuxoko commented May 23, 2017

  1. Fix import can't find spare/l2cache when path change

When spare or l2cache device path changes, zpool import will not fix up
their paths like normal vdev. The issue is that when you supply a pool
name argument to zpool import, it will use it to filter out device which
doesn't have the pool name in the label. Since spare and l2cache device
never have that in the label, they'll always get filtered out.

We fix this by making sure we never filter out a spare or l2cache
device.

  1. Fix import wrong spare/l2 device when path change

If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Description

Motivation and Context

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the ZFS on Linux code style requirements.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • All commit messages are properly formatted and contain Signed-off-by.
  • Change has been approved by a ZFS on Linux member.

@mention-bot
Copy link

@tuxoko, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @don-brady and @tonyhutter to be potential reviewers.

@tuxoko tuxoko requested review from behlendorf and tonyhutter May 24, 2017 19:05
@tuxoko
Copy link
Contributor Author

tuxoko commented May 24, 2017

@tonyhutter
Can you make this as a dependency for 0.6.5.10?

/*
* Check if it's a spare or l2cache device. If it is,
* we need to skip the name and guid check since they
* don't exists on aux devcie label.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo "device"

otherwise LGTM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@dinatale2
Copy link
Contributor

@tuxoko Looks like the buildbot may not have seen the change. Would you mind pushing it again?

When spare or l2cache device path changes, zpool import will not fix up
their paths like normal vdev. The issue is that when you supply a pool
name argument to zpool import, it will use it to filter out device which
doesn't have the pool name in the label. Since spare and l2cache device
never have that in the label, they'll always get filtered out.

We fix this by making sure we never filter out a spare or l2cache
device.

Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
@lundman
Copy link
Contributor

lundman commented May 24, 2017

Does this commit address the problem when the device is there, but is not the log/cache device expected? In OsX we have to find a solution for that as OpenZFS will just open any device it finds, if it happens to have the name of another pool's log/cache device, then write all over it. Destroying any data already on the device, be it another zpool, or hfs/fat/ext3. Which is true if you use /dev/disk (/dev/sdX) path names. (Luckily, most users use by-id these days).

@tuxoko
Copy link
Contributor Author

tuxoko commented May 24, 2017

@lundman
It seems it depends on whether the correct device is present. If it is then with this patch zpool import will switch to the correct device. However, if the correct device is not present, it will still use the wrong device.

@lundman
Copy link
Contributor

lundman commented May 24, 2017

Righto, I'll leave it on the todo for us.. What OsX really need is for log/cache devices to be labelled :)

If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
@tuxoko
Copy link
Contributor Author

tuxoko commented May 26, 2017

Add a fix for import using wrong spare/l2 device.

@tonyhutter
Copy link
Contributor

@tuxoko I'll give this a test on my VM

@tonyhutter
Copy link
Contributor

I was able to verify that this does fix the case of a spare moving from /dev/sdb to /dev/sdc. Before it would say the spare was missing, but after it correctly found the spare at /dev/sdc.

I also tried corrupting a device (#6158 (comment)) by creating it as a spare or cache in a pool, exporting the pool, zeroing the device, and then importing the pool again. I was expecting to see the zero'd device get corrupted with a new label, but instead zpool just listed it as UNAVAIL, and the device remained zeroed. @tuxoko were you able to corrupt a device in your testing? Or is it just a OSX issue?

@tuxoko
Copy link
Contributor Author

tuxoko commented May 26, 2017

@tonyhutter
It did corrupt the disk in my test.

@tonyhutter
Copy link
Contributor

@tuxoko can your describe your test setup for corrupting the disk? I'd like to try it on my VM.

@tuxoko
Copy link
Contributor Author

tuxoko commented May 26, 2017

@tonyhutter
Did the zfs create partition for you? If so you need to do partition after you zero the disk.

VDEV_ALLOC_SPARE);
if (error == 0)
error = spa_validate_aux(spa, nvroot, -1ULL,
VDEV_ALLOC_L2CACHE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropping these checks will result in the shared aux device tests being disabled during import. That shouldn't be a problem since these checks only make sense during zpool create and zpool add. At import time we shouldn't be re-initializing any devices and instead only verifying that the required devices all have valid labels,

@behlendorf behlendorf closed this in 2e9c8db Jun 1, 2017
behlendorf pushed a commit that referenced this pull request Jun 1, 2017
If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes #6158
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jun 7, 2017
When spare or l2cache device path changes, zpool import will not fix up
their paths like normal vdev. The issue is that when you supply a pool
name argument to zpool import, it will use it to filter out device which
doesn't have the pool name in the label. Since spare and l2cache device
never have that in the label, they'll always get filtered out.

We fix this by making sure we never filter out a spare or l2cache
device.

Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes openzfs#6158
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jun 7, 2017
If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes openzfs#6158
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jun 8, 2017
When spare or l2cache device path changes, zpool import will not fix up
their paths like normal vdev. The issue is that when you supply a pool
name argument to zpool import, it will use it to filter out device which
doesn't have the pool name in the label. Since spare and l2cache device
never have that in the label, they'll always get filtered out.

We fix this by making sure we never filter out a spare or l2cache
device.

Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes openzfs#6158
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Jun 8, 2017
If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes openzfs#6158
tonyhutter pushed a commit that referenced this pull request Jun 9, 2017
When spare or l2cache device path changes, zpool import will not fix up
their paths like normal vdev. The issue is that when you supply a pool
name argument to zpool import, it will use it to filter out device which
doesn't have the pool name in the label. Since spare and l2cache device
never have that in the label, they'll always get filtered out.

We fix this by making sure we never filter out a spare or l2cache
device.

Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes #6158
tonyhutter pushed a commit that referenced this pull request Jun 9, 2017
If, for example, your aux device was /dev/sdc, but now the aux device is
removed and /dev/sdc points to other device. zpool import will still
use that device and corrupt it.

The problem is that the spa_validate_aux in spa_import, rather than
validate the on-disk label, it would actually write label to disk. We
remove them since spa_load_{spares,l2cache} seems to do everything we
need and they would actually validate on-disk label.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <david.chen@osnexus.com>
Closes #6158
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants