Создание пула ZFS из liveCD с ashift = 9 становится ashift = 12 при перезагрузке в новую ОС

Я создал zpool при загрузке на liveCD Linux Mint (со всеми пакетами ZFS temp apt -installed) и создал zpool с командной строкой, содержащей ashift = 9 , потому что мои диски ST4000NM0033 (по 8 на каждом) имеют секторы 512B. Также были созданы некоторые файловые системы ZFS в пуле при использовании LiveCD

При работе liveCD , Затем я смог убедиться, что пул использует ashift = 9, выполнив zdb -e -C pool0 | grep ashift . пришлось использовать параметры -e -C pool0 , потому что без них я получал не могу открыть /etc/zfs/zpool.cache ошибку

Но как только я установил и перезагрузился в реальная ОС, которая представляет собой ZFS в корневом каталоге, и перезапущена zdb | grep ashift он сообщает ashift = 12

Я также использую LUKS под vdevs. У каждого есть отдельный заголовок и ключевой файл, и я загружаю систему с USB-ключа с помощью grub / efi / boot на нем.

zpool - это 2-х дисковый RAIDZ1 с 4 дисками.

zpool details:

щелкните для подробностей рис. он не будет вставлен правильно

Вот результаты zdb в работающей системе

version: 5000
name: 'pool0'
state: 0
txg: 331399
pool_guid: 4878817387727202324
errata: 0
hostname: 'shop'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
    type: 'root'
    id: 0
    guid: 4878817387727202324
    children[0]:
        type: 'raidz'
        id: 0
        guid: 4453362395566037229
        nparity: 1
        metaslab_array: 138
        metaslab_shift: 36
        ashift: 12
        asize: 7996794994688
        is_log: 0
        create_txg: 4
        com.delphix:vdev_zap_top: 129
        children[0]:
            type: 'disk'
            id: 0
            guid: 17425041855122083436
            path: '/dev/mapper/luks_root_sda'
            whole_disk: 0
            DTL: 179
            create_txg: 4
            com.delphix:vdev_zap_leaf: 130
        children[1]:
            type: 'disk'
            id: 1
            guid: 14306620094487281535
            path: '/dev/mapper/luks_root_sdb'
            whole_disk: 0
            DTL: 178
            create_txg: 4
            com.delphix:vdev_zap_leaf: 131
        children[2]:
            type: 'disk'
            id: 2
            guid: 16566898459604505385
            path: '/dev/mapper/luks_root_sdc'
            whole_disk: 0
            DTL: 177
            create_txg: 4
            com.delphix:vdev_zap_leaf: 132
        children[3]:
            type: 'disk'
            id: 3
            guid: 542095292802891028
            path: '/dev/mapper/luks_root_sdd'
            whole_disk: 0
            DTL: 176
            create_txg: 4
            com.delphix:vdev_zap_leaf: 133
        children[4]:
            type: 'disk'
            id: 4
            guid: 14142266371747430354
            path: '/dev/mapper/luks_root_sde'
            whole_disk: 0
            DTL: 175
            create_txg: 4
            com.delphix:vdev_zap_leaf: 134
        children[5]:
            type: 'disk'
            id: 5
            guid: 9998698084287190219
            path: '/dev/mapper/luks_root_sdf'
            whole_disk: 0
            DTL: 174
            create_txg: 4
            com.delphix:vdev_zap_leaf: 135
        children[6]:
            type: 'disk'
            id: 6
            guid: 9268711926727287907
            path: '/dev/mapper/luks_root_sdg'
            whole_disk: 0
            DTL: 173
            create_txg: 4
            com.delphix:vdev_zap_leaf: 136
        children[7]:
            type: 'disk'
            id: 7
            guid: 16360862201213710466
            path: '/dev/mapper/luks_root_sdh'
            whole_disk: 0
            DTL: 172
            create_txg: 4
            com.delphix:vdev_zap_leaf: 137
features_for_read:
    com.delphix:hole_birth
    com.delphix:embedded_data

ОБНОВЛЕНИЕ: Кажется, проверка значения ashift непосредственно на устройстве показывает ожидаемое ashift = 9 значение. Не уверен, почему значение верхнего уровня отличается

zdb -l / dev / mapper / luks_root_sda

LABEL 0

version: 5000
name: 'pool0'
state: 0
txg: 2223
pool_guid: 13689528332972152746
errata: 0
hostname: 'shop'
top_guid: 8586701185874218688
guid: 11289841240384277392
vdev_children: 2
vdev_tree:
    type: 'raidz'
    id: 0
    guid: 8586701185874218688
    nparity: 1
    metaslab_array: 142
    metaslab_shift: 37
    ashift: 9
    asize: 15901962272768
    is_log: 0
    create_txg: 4
    children[0]:
        type: 'disk'
        id: 0
        guid: 11289841240384277392
        path: '/dev/mapper/luks_root_sda'
        whole_disk: 0
        create_txg: 4
    children[1]:
        type: 'disk'
        id: 1
        guid: 7916996642850715828
        path: '/dev/mapper/luks_root_sdb'
        whole_disk: 0
        create_txg: 4
    children[2]:
        type: 'disk'
        id: 2
        guid: 5366943858334839242
        path: '/dev/mapper/luks_root_sdc'
        whole_disk: 0
        create_txg: 4
    children[3]:
        type: 'disk'
        id: 3
        guid: 3110382675821028014
        path: '/dev/mapper/luks_root_sdd'
        whole_disk: 0
        create_txg: 4
features_for_read:
    com.delphix:hole_birth
    com.delphix:embedded_data
labels = 0 1 2 3
3
задан 11 December 2019 в 21:17
1 ответ

Эта проблема была вызвана устаревшим /etc/zfs/zpool.cache, который был скопирован в место, когда я заменил установку на 8x1 ТБ новым массивом на 8x4 ТБ и скопировал исходный / корень назад в место.

Кажется, что ZFS не обновил zpool.cache и zdb -l чтения из того файла, тогда как zdb -l /dev/DEVICE | grep ashift чтения от zdev непосредственно и показали ожидаемое значение ashift=9.

Для исправления всей проблемы я удалил zpool.cache и выполнился zpool set cachefile=/etc/zfs/zpool.cache pool0

0
ответ дан 31 December 2019 в 11:48

Теги

Похожие вопросы