Project

General

Profile

Actions

Bug #4958

closed

zdb trips assert on pools with ashift >= 0xe

Added by Alex Reece over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2014-07-02
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

When building pools of ashift >= 0xe, zdb has troubles:

We
can build pools from these volumes, and when we do zdb has trouble with
some of the larger ashifts (0xe - 0x11).

Loading modules: [ libumem.so.1 libc.so.1 libzpool.so.1 libavl.so.1
libcmdutils.so.1 libnvpair.so.1 libtopo.so.1 ld.so.1 ]
> $C
fffffd7fffdff1f0 libc.so.1`_lwp_kill+0xa()
fffffd7fffdff580 libc.so.1`_assfail+0x179(fffffd7ffb3ca350, fffffd7ffb3c8e30,
989)
fffffd7fffdff5b0 libc.so.1`assfail+0x19(fffffd7ffb3ca350, fffffd7ffb3c8e30,
989)
fffffd7fffdff610 libzpool.so.1`zio_vdev_io_start+0x250(de03b0)
fffffd7fffdff660 libzpool.so.1`zio_execute+0xda(de03b0)
fffffd7fffdff690 libzpool.so.1`zio_nowait+0x43(de03b0)
fffffd7fffdff730 libzpool.so.1`vdev_probe+0x12c(de4a00, 0)
fffffd7fffdff7a0 libzpool.so.1`vdev_open+0x401(de4a00)
fffffd7fffdff7f0 libzpool.so.1`vdev_open_children+0x62(de5240)
fffffd7fffdff850 libzpool.so.1`vdev_root_open+0x7d(de5240, fffffd7fffdff878,
fffffd7fffdff870, fffffd7fffdff868)
fffffd7fffdff8c0 libzpool.so.1`vdev_open+0x1cd(de5240)
fffffd7fffdff9b0 libzpool.so.1`spa_load_impl+0x1ad(d9a800, 97bfd4128b55382a,
47aac0, 1, 0, 0)
fffffd7fffdffa40 libzpool.so.1`spa_load+0x161()
fffffd7fffdffae0 libzpool.so.1`spa_load_best+0x6b(d9a800, 1, 0,
ffffffffffffffff, 2)
fffffd7fffdffb80 libzpool.so.1`spa_open_common+0x178(fffffd7fffdffe24,
fffffd7fffdffc38, 410d60, 47ae80, 0)
fffffd7fffdffbc0 libzpool.so.1`spa_open_rewind+0x21(fffffd7fffdffe24,
fffffd7fffdffc38, 410d60, 47ae80, 0)
fffffd7fffdffc80 main+0x380(2, fffffd7fffdffca8)
fffffd7fffdffc90 _start+0x6c()

The problem is that zio_probe will "read and write to several known locations:
the pad regions of each vdev label". According the the zfs on-disk format, this
is an 8k aligned region. If your ashift is larger than 8k, you will trip an
assert in zio_vdev_io_start:

assertion failed for thread 0xfffffd7fff172a40, thread-id 1:
P2PHASE(zio->io_offset, align) == 0, file ../../../uts/common/fs/zfs/zio.c

libc.so.1`assfail+0x19(fffffd7ffaa60730, fffffd7ffaa5f1d8, 992)
libzpool.so.1`zio_vdev_io_start+0x248(da33a0)
libzpool.so.1`zio_execute+0xda(da33a0)
libzpool.so.1`zio_nowait+0x43(da33a0)
libzpool.so.1`vdev_probe+0x11e(da60c0, 0)

Furthermore, the uberblock is sized according to the ashift:

#define VDEV_UBERBLOCK_RING     (128 << 10)                                     

#define VDEV_UBERBLOCK_SHIFT(vd)        \\                                       
        MAX((vd)->vdev_top->vdev_ashift, UBERBLOCK_SHIFT)                       
#define VDEV_UBERBLOCK_COUNT(vd)        \\                                       
        (VDEV_UBERBLOCK_RING >> VDEV_UBERBLOCK_SHIFT(vd))      

If ashift is log(128k), we will only have one uberblock.

We should cap the uberblock size at 8k to prevent these issues.

Actions #1

Updated by Electric Monk over 8 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

git commit 2a104a5236475eb73aa41eaaf3ed9f3ccbe0ca55

commit  2a104a5236475eb73aa41eaaf3ed9f3ccbe0ca55
Author: Alex Reece <alex@delphix.com>
Date:   2014-07-16T20:09:51.000Z

    4958 zdb trips assert on pools with ashift >= 0xe
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: Max Grossman <max.grossman@delphix.com>
    Reviewed by: George Wilson <george.wilson@delphix.com>
    Reviewed by: Christopher Siden <christopher.siden@delphix.com>
    Approved by: Garrett D'Amore <garrett@damore.org>

Actions

Also available in: Atom PDF