LINUX.ORG.RU
решено ФорумAdmin

ZFS: zpool - перенос на другой хост (экспорт/импорт) проблема....

 ,


0

2

Преамбула: есть хост раздающий тома LVM через FC посредством SCST. Кроме всего прочего, к нему подключен JBOD (шасси с дисками). Изначально часть дисков использовалась под LVM+FC+SCST. Когда вышел релиз ZoL возникла мысль попробовать ZFS. Чтобы не экспериментировать на «боевом» хосте я оставшуюся часть дисков экспортировал на другой хост (через FC+scst_vdisk), к которому физически подключить диски другой возможности нет (это резервный «блейд» в шасси без SAS/SATA модуля). На этом, тестовом хосте, я собрал пул ZFS, поигрался, посоздавал тома с реальными данными, все понравилось...

Амбула: Теперь я решил перенести ZFS-пул на основной хост. Остановил все, что пользуется этим пулом, экспортировал пул, отключил SCSI диски пула в ОС, отключил экспорт дисков по FC на основном хосте.

Делаю на основном хосте zpool import, и что я вижу:

host:/etc # zpool import -d /dev/disk/by-vdev
   pool: RAID-10
     id: 149897041700488127
  state: UNAVAIL
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
 config:

        RAID-10      UNAVAIL  insufficient replicas
          mirror-0   UNAVAIL  insufficient replicas
            D-1      UNAVAIL
            M-1      UNAVAIL
          mirror-1   UNAVAIL  insufficient replicas
            D-2      UNAVAIL
            M-2      UNAVAIL
          mirror-2   UNAVAIL  insufficient replicas
            D-3      UNAVAIL
            M-3      UNAVAIL
          mirror-3   UNAVAIL  insufficient replicas
            D-4      UNAVAIL
            M-4      UNAVAIL
          mirror-4   UNAVAIL  insufficient replicas
            D-6      UNAVAIL
            M-6      UNAVAIL
          mirror-5   DEGRADED
            D-5      UNAVAIL
            M-5      ONLINE
          mirror-6   UNAVAIL  insufficient replicas
            D-7      UNAVAIL
            M-7      UNAVAIL
        logs
          SSD-part1  ONLINE
Восстановил экспорт дисков, импортирую на тестовом хосте:
tst-host:/# zpool status RAID-10
  pool: RAID-10
 state: ONLINE
config:

        NAME         STATE     READ WRITE CKSUM
        RAID-10      ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            D-1      ONLINE       0     0     0
            M-1      ONLINE       0     0     0
          mirror-1   ONLINE       0     0     0
            D-2      ONLINE       0     0     0
            M-2      ONLINE       0     0     0
          mirror-2   ONLINE       0     0     0
            D-3      ONLINE       0     0     0
            M-3      ONLINE       0     0     0
          mirror-3   ONLINE       0     0     0
            D-4      ONLINE       0     0     0
            M-4      ONLINE       0     0     0
          mirror-4   ONLINE       0     0     0
            D-6      ONLINE       0     0     0
            M-6      ONLINE       0     0     0
          mirror-5   ONLINE       0     0     0
            D-5      ONLINE       0     0     0
            M-5      ONLINE       0     0     0
          mirror-6   ONLINE       0     0     0
            D-7      ONLINE       0     0     0
            M-7      ONLINE       0     0     0
        logs
          SSD-part1  ONLINE       0     0     0
        spares
          SPARE      AVAIL

errors: No known data errors
Вопрос в том, как импортировать пул на основном хосте? Версия ZFS одиакова (ZFS скомпилена на обеих хостах с одних и тех-же src.rpm)

Теоретически можно перенести данные через zfs send/receive, но неначем собрать еще один пул достаточной емкости, а «отцепить» часть дисков из пула ZFS не разрешает....

ЗЫ: ладно-бы на основном хосте все диски были-бы в состоянии UNAVAIL, но раздел лога и один диск «онлайн»...

ЗЫЗЫ: если важно, оба хоста openSUSE 13.1

вероятно при импорте не может найти диски по тем именам, под которыми они были на исходном хосте. Не силен в велосипеде, что вы нагородили, но надо проверить для начала эту версию.

zgen ★★★★★
()
Ответ на: комментарий от Lordwind

Выключи дедубликацию, если есть, прогони скраб.

Зачетные вещества употребляешь

anonymous
()
Ответ на: комментарий от zgen

для удобочитаемости в именовании дисков использую vdev_id

конфиг на обеих хостах одинаков:

# cat /etc/zfs/vdev_id.conf|grep alias|grep -v '#'
alias D-1       /dev/disk/by-id/wwn-0x5000cca224edec86
alias M-1       /dev/disk/by-id/wwn-0x5000cca224ede11a
alias D-2       /dev/disk/by-id/wwn-0x5000cca224edec91
alias M-2       /dev/disk/by-id/wwn-0x5000cca224ededef
alias D-3       /dev/disk/by-id/wwn-0x5000cca224edec81
alias M-3       /dev/disk/by-id/wwn-0x5000cca224ed935b
alias D-4       /dev/disk/by-id/wwn-0x5000cca224ed2be1
alias M-4       /dev/disk/by-id/wwn-0x5000cca224ed9331
alias D-5       /dev/disk/by-id/wwn-0x5000cca224ed934d
alias M-5       /dev/disk/by-id/wwn-0x5000cca224edec80
alias D-6       /dev/disk/by-id/wwn-0x5000cca224edbeec
alias M-6       /dev/disk/by-id/wwn-0x5000cca224ed934c
alias D-7       /dev/disk/by-id/wwn-0x5000cca224ed1e6b
alias M-7       /dev/disk/by-id/wwn-0x5000cca224ed9347
alias SSD       /dev/disk/by-id/wwn-0x55cd2e404b429c5a
alias SPARE     /dev/disk/by-id/wwn-0x5000cca224edec8f
диски на обеих хостах доступны: на тестовом:
 # lsscsi|grep ATA
[2:0:4:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdc
[2:0:4:1]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdd
[2:0:4:2]    disk    ATA      Hitachi HUA72302 AA10  /dev/sde
[2:0:4:3]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdf
[2:0:4:4]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdg
[2:0:4:5]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdh
[2:0:4:6]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdi
[2:0:4:7]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdj
[2:0:4:8]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdk
[2:0:4:9]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdl
[2:0:4:10]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdm
[2:0:4:11]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdn
[2:0:4:12]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdo
[2:0:4:13]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdp
[2:0:4:14]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdq
[2:0:4:15]   disk    ATA      INTEL SSDSC2BA40 0270  /dev/sdr

 # ls -lh /dev/disk/by-vdev|grep -v part
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-1 -> ../../sdf
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-2 -> ../../sdd
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-3 -> ../../sdj
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-4 -> ../../sdh
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-5 -> ../../sdn
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-6 -> ../../sdl
lrwxrwxrwx 1 root root  9 Mar 27 20:54 D-7 -> ../../sdp
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-1 -> ../../sde
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-2 -> ../../sdc
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-3 -> ../../sdi
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-4 -> ../../sdg
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-5 -> ../../sdm
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-6 -> ../../sdk
lrwxrwxrwx 1 root root  9 Mar 27 20:54 M-7 -> ../../sdo
lrwxrwxrwx 1 root root  9 Mar 27 20:54 SPARE -> ../../sdq
lrwxrwxrwx 1 root root  9 Mar 27 20:54 SSD -> ../../sdr

на «боевом»:

# lsscsi|grep ATA
[4:0:0:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sde
[4:0:1:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdf
[4:0:2:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdg
[4:0:3:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdh
[4:0:4:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdi
[4:0:5:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdj
[4:0:6:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdk
[4:0:7:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdl
[4:0:8:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdm
[4:0:9:0]    disk    ATA      Hitachi HUA72302 AA10  /dev/sdn
[4:0:10:0]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdo
[4:0:11:0]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdp
[4:0:12:0]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdq
[4:0:13:0]   disk    ATA      Hitachi HUA72302 AA10  /dev/sdr
[4:0:14:0]   disk    ATA      Hitachi HUA72302 AA10  /dev/sds
[4:0:15:0]   disk    ATA      INTEL SSDSC2BA40 0270  /dev/sdt

 # ls -lh /dev/disk/by-vdev/|grep -v part
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-1 -> ../../sdh
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-2 -> ../../sdf
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-3 -> ../../sdl
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-4 -> ../../sdj
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-5 -> ../../sdp
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-6 -> ../../sdn
lrwxrwxrwx 1 root root  9 Mar 27 22:28 D-7 -> ../../sdr
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-1 -> ../../sdg
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-2 -> ../../sde
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-3 -> ../../sdk
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-4 -> ../../sdi
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-5 -> ../../sdo
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-6 -> ../../sdm
lrwxrwxrwx 1 root root  9 Mar 27 22:28 M-7 -> ../../sdq
lrwxrwxrwx 1 root root  9 Mar 27 22:28 SPARE -> ../../sds
lrwxrwxrwx 1 root root  9 Mar 27 22:28 SSD -> ../../sdt

для сравнения (один и тот-же wwn):

боевой:

 # fdisk -l /dev/disk/by-id/wwn-0x5000cca224ededef
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/disk/by-id/wwn-0x5000cca224ededef: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048   3907012607    1.8T  Solaris /usr &  zfs
 9   3907012608   3907028991      8M  Solaris reserve
тестовый:
 # fdisk -l /dev/disk/by-id/wwn-0x5000cca224ededef
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/disk/by-id/wwn-0x5000cca224ededef: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048   3907012607    1.8T  Solaris /usr &  zfs
 9   3907012608   3907028991      8M  Solaris reserve

разница лишь в том, что на «боевом» диски доступны через SAS-контроллер, а на тестовом через FC-контроллер...

Sigizmund
() автор топика
Ответ на: комментарий от anton_jugatsu

Дай вывод zpool status с ключом -v.

 # zpool status -v RAID-10
  pool: RAID-10
 state: ONLINE
  scan: scrub repaired 0 in 29h25m with 0 errors on Sun Mar 29 02:57:33 2015
config:

        NAME         STATE     READ WRITE CKSUM
        RAID-10      ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            D-1      ONLINE       0     0     0
            M-1      ONLINE       0     0     0
          mirror-1   ONLINE       0     0     0
            D-2      ONLINE       0     0     0
            M-2      ONLINE       0     0     0
          mirror-2   ONLINE       0     0     0
            D-3      ONLINE       0     0     0
            M-3      ONLINE       0     0     0
          mirror-3   ONLINE       0     0     0
            D-4      ONLINE       0     0     0
            M-4      ONLINE       0     0     0
          mirror-4   ONLINE       0     0     0
            D-6      ONLINE       0     0     0
            M-6      ONLINE       0     0     0
          mirror-5   ONLINE       0     0     0
            D-5      ONLINE       0     0     0
            M-5      ONLINE       0     0     0
          mirror-6   ONLINE       0     0     0
            D-7      ONLINE       0     0     0
            M-7      ONLINE       0     0     0
        logs
          SSD-part1  ONLINE       0     0     0
        spares
          SPARE      AVAIL

errors: No known data errors
Sigizmund
() автор топика

это проблема с именами блочных устройств. на имена типа /dev/sda, /dev/sdb не смотри и не используй их, используй диски по их /dev/disk/by-path

anonymous
()
Ответ на: комментарий от Sigizmund

смотрим маны про состояние UNAVAIL - http://www.freebsd.org/cgi/man.cgi?zpool(8)

 UNAVAIL   The device could not be opened. If a pool is imported when a device was unavailable, then the device will be identified by a unique identifier instead of its path since the path was never correct in the first place.

https://docs.oracle.com/cd/E19253-01/820-0836/gbchy/index.html

anonymous
()
Ответ на: комментарий от anonymous

смотрим маны про состояние UNAVAI

эти маны не дают ответ на вопрос почему они недоступны, в то время как в системе диски видны, кроме того, 1 диск из массива онлайн и диск логов онлайн...

Sigizmund
() автор топика
Ответ на: комментарий от anonymous

убей кеш пула.

на «боевом» хосте еще кеша нет, т.к. ZFS там еще не использовалась

посмотри на предмет отличий у дисков
zdb -l /dev/sdb

Сравнил что показывает zdb на диске, который онлайн (в моей конфигурации М-5) - на обеих хостах идентично. А вот на D-5 есть отличия....

# diff -y lvm-D-5-part1.txt blade-D-5-part1.txt
--------------------------------------------                    --------------------------------------------
LABEL 0                                                         LABEL 0
--------------------------------------------                    --------------------------------------------
    version: 5000                                                   version: 5000
    name: 'RAID-10'                                                 name: 'RAID-10'
    state: 1                                                  |     state: 0
    txg: 5613445                                              |     txg: 5614068
    pool_guid: 149897041700488127                                   pool_guid: 149897041700488127
    errata: 0                                                       errata: 0
    hostname: 'blade-lvm'                                           hostname: 'blade-lvm'
    top_guid: 10858593200884775612                                  top_guid: 10858593200884775612
    guid: 1180437747787329176                                       guid: 1180437747787329176
    vdev_children: 8                                                vdev_children: 8
    vdev_tree:                                                      vdev_tree:
        type: 'mirror'                                                  type: 'mirror'
        id: 5                                                           id: 5
        guid: 10858593200884775612                                      guid: 10858593200884775612
        metaslab_array: 464                                             metaslab_array: 464
        metaslab_shift: 34                                              metaslab_shift: 34
        ashift: 9                                                       ashift: 9
        asize: 2000384688128                                            asize: 2000384688128
        is_log: 0                                                       is_log: 0
        create_txg: 352376                                              create_txg: 352376
        children[0]:                                                    children[0]:
            type: 'disk'                                                    type: 'disk'
            id: 0                                                           id: 0
            guid: 1180437747787329176                                       guid: 1180437747787329176
            path: '/dev/disk/by-vdev/D-5-part1'                             path: '/dev/disk/by-vdev/D-5-part1'
            whole_disk: 1                                                   whole_disk: 1
            DTL: 519                                                        DTL: 519
            create_txg: 352376                                              create_txg: 352376
        children[1]:                                                    children[1]:
            type: 'disk'                                                    type: 'disk'
            id: 1                                                           id: 1
            guid: 13982846923962037507                                      guid: 13982846923962037507
            path: '/dev/disk/by-vdev/M-5-part1'                             path: '/dev/disk/by-vdev/M-5-part1'
            whole_disk: 1                                                   whole_disk: 1
            DTL: 518                                                        DTL: 518
            create_txg: 352376                                              create_txg: 352376
    features_for_read:                                              features_for_read:
--------------------------------------------                    --------------------------------------------
LABEL 1                                                         LABEL 1
--------------------------------------------                    --------------------------------------------
    version: 5000                                                   version: 5000
    name: 'RAID-10'                                                 name: 'RAID-10'
    state: 1                                                  |     state: 0
    txg: 5613445                                              |     txg: 5614068
    pool_guid: 149897041700488127                                   pool_guid: 149897041700488127
    errata: 0                                                       errata: 0
    hostname: 'blade-lvm'                                           hostname: 'blade-lvm'
    top_guid: 10858593200884775612                                  top_guid: 10858593200884775612
    guid: 1180437747787329176                                       guid: 1180437747787329176
    vdev_children: 8                                                vdev_children: 8
    vdev_tree:                                                      vdev_tree:
        type: 'mirror'                                                  type: 'mirror'
        id: 5                                                           id: 5
        guid: 10858593200884775612                                      guid: 10858593200884775612
        metaslab_array: 464                                             metaslab_array: 464
        metaslab_shift: 34                                              metaslab_shift: 34
        ashift: 9                                                       ashift: 9
        asize: 2000384688128                                            asize: 2000384688128
        is_log: 0                                                       is_log: 0
        create_txg: 352376                                              create_txg: 352376
        children[0]:                                                    children[0]:
            type: 'disk'                                                    type: 'disk'
            id: 0                                                           id: 0
            guid: 1180437747787329176                                       guid: 1180437747787329176
            path: '/dev/disk/by-vdev/D-5-part1'                             path: '/dev/disk/by-vdev/D-5-part1'
            whole_disk: 1                                                   whole_disk: 1
            DTL: 519                                                        DTL: 519
            create_txg: 352376                                              create_txg: 352376
        children[1]:                                                    children[1]:
            type: 'disk'                                                    type: 'disk'
            id: 1                                                           id: 1
            guid: 13982846923962037507                                      guid: 13982846923962037507
            path: '/dev/disk/by-vdev/M-5-part1'                             path: '/dev/disk/by-vdev/M-5-part1'
            whole_disk: 1                                                   whole_disk: 1
            DTL: 518                                                        DTL: 518
            create_txg: 352376                                              create_txg: 352376
    features_for_read:                                              features_for_read:

2 последние метки одинаковы....

zdb на тестовом хосте на обеих дисках везде показывает "state: 0"....

хм...может нужно было кроме экспорта пула на тестовом сервере его по питанию потушить или, хотя-бы, модуль ZFS "выгрузить"?

>импортируй так
>zpool import -f -d /dev/disk/by-path 8888155799507994447

с этим пока подожду...сначала по максимуму распихаю с пула данные да бекапов наделаю.... :)))
Sigizmund
() автор топика
Ответ на: комментарий от Sigizmund

txg: 5613445 | txg: 5614068

У тебя на дисках метки разных версий. Попробуй 'zpool import -F -o readonly=on your_pool' или грепни zdb txg всех дисков, если с -F сам не откатит на предыдущие, и попробуй импортировать самую старую транзакцию 'zpool import -T txg_nr -o readonly=on your_pool'. если добавить к -Fn, то будет т.н. dry run в ходе которого в реальности ничего импортировано не будет.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

подстрахуюсь бекапами и попробую еще раз потушив тестовый по питанию...

после того как сделал echo 3 > /proc/sys/vm/drop_caches на обеих хостах на всех метках стало «state: 0»...

есть подозрение что не все с памяти на диски было сброшено...

Sigizmund
() автор топика
Ответ на: комментарий от Sigizmund

подстрахуюсь бекапами и попробую еще раз потушив тестовый по питанию...

после того как сделал echo 3 > /proc/sys/vm/drop_caches на обеих хостах на всех метках стало «state: 0»...

есть подозрение что не все с памяти на диски было сброшено...

Как это по-ляликсовски. А ведь потом апологеты ляликса будут ссылаться сюда и заявлять, какое дерьмо эта ваша заливная рыба. В то время как рыба - это ляликс. Проигнорировать три команды на сброс кашей диска при последнем обновлении ZFS-меток дисков - это надо сильно постараться.

Btw, «state: 0» соответствует пулу, который активен или не был экспортирован или уничтожен, а «state: 1» соответствует экспортированному пулу. То, что у тебя txt на диске, где «state: 0» больше, чем на том, где «state: 1», говорит о том, что нифига он у тебя не экспортирован, как следует, ну или после экспорта был импортирован снова на том же хосте с именем blade-lvm. А из предыдущих выхлопом у тебя хосты называются host и tst-host.

Ты уверен, что ничего не накосячил?

anonymous
()
Ответ на: комментарий от anonymous

все события происходили 27.03.2015 вечером, а тему я создал в уже в субботу...

пул я экспортировал, но после неудачной попытки импорта все вернул взад....работать-то нада...

а те листинги я уже приводил на активном пуле на тестовом (который blade-lvm) т.к. на основном картина не поменялась несмотря на импорт (М-5 как был онлайн так и остался, так-же как и раздел лога)...а за кеши да, похоже не учел....понадеялся что ZFS додумается при экспорте сбросить кеш на диск....хотя еще проверить нада...

Sigizmund
() автор топика
Ответ на: комментарий от Sigizmund

а за кеши да, похоже не учел....понадеялся что ZFS додумается при экспорте сбросить кеш на диск

она именно это и делает в более других системах, в линуксе, видимо, как обычно.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

она именно это и делает в более других системах, в линуксе, видимо, как обычно.

Ну и гов не готов ZoL для продакшена, как не крути.

anonymous
()
Ответ на: комментарий от anonymous

Не кипятись, это было адресовано в пространство )

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Sigizmund

а за кеши да, похоже не учел....понадеялся что ZFS додумается при экспорте сбросить кеш на диск....

Как ты мастерски перекладываешь с больной головы на здоровую! Я бы на твоем месте серьезно задумался - косяк ли это в твоей конфигурации или косяк в ляликсе. И если это косяк в ляликсе, то серьезно задумался бы еще раз на предмет, стоит ли такой ляликс использовать для чего-то более-менее ответственного.

anonymous
()
Ответ на: комментарий от anonymous

Ну и гов не готов ZoL для продакшена, как не крути.

Это еще вопрос, кто не готов - ZoL или собственно ляликс.

anonymous
()
Ответ на: комментарий от Sigizmund

Процедуру переноса пула на другие хосты делал так:

На хосте с пулом собраном на локальных дисках стопорим все процессы эксплутирующие пул, делаю sync, экспортирую пул, гашу сервант, вынимаю диски. Вставляю диски на горячую в другой сервант, смотрю идентификатор пула (pool_guid) командой zdb -l /dev/sdd, импортируют пул zpool import -f -d /dev/disk/by-path (pool_guid), не знаю насколько имеет значение но для имен устройств использую именно by-path.

axelroot
()
Ответ на: комментарий от axelroot

да все в порядке в linux с импортом/экспортом пулов если не заниматься извращениями и экстримом.

я заметил, как всё в порядке, особенно доставляет

стопорим все процессы эксплутирующие пул, делаю sync, экспортирую пул, гашу сервант

по-твоему как раз всё наоборот выходит - в порядке, если заниматься извращениями. впрочем, как обычно :)

EvgGad_303 ★★★★★
()
Ответ на: комментарий от anonymous

я ничего не перекладываю...это было предположение требующее проверки...

Sigizmund
() автор топика

Вобщем все импортировалось :)

Диски раньше использовались для экспериментов с dm-raid и, невзирая на то, что разделов рейда на них нет, он находил свои метки на дисках и пытался собрать рейд=блокировал диски. Убил рейд - все импортировалось...Так-что кеши непричем... :)

Sigizmund
() автор топика
Ответ на: комментарий от Sigizmund

Диски раньше использовались для экспериментов с dm-raid и, невзирая на то, что разделов рейда на них нет, он находил свои метки на дисках и пытался собрать рейд=блокировал диски. Убил рейд - все импортировалось...

И вот так в этом ляликсе куда ни плюнь.

А почему тогда на другом хосте импортировалось? Или там dm-raid не было?

Так-что кеши непричем... :)

Может быть, но это не значит, что не стоит задуматься о том, где собака порылась.

anonymous
()
Ответ на: комментарий от EvgGad_303

хорошо, пускай sync и выключение сервера - это будут особенности.

Там же извлечение дисков еще требовалось, не у всех ведь сервер отключение/извлечение дисков на лету умеет

anonymous
()
Ответ на: комментарий от anonymous

И вот так в этом ляликсе куда ни плюнь.

Ну....по «букве закона» после убивания рейда нужно было сделать dmsetup clear device_name, но и zfs могла-бы при создании пула грохнуть известные чужие метки (ведь о том, что диски возможно используются для рейда оно меня предупреждало, значит метки рейда знает)

Или там dm-raid не было?

Да, там dm-raid не использовался...

Sigizmund
() автор топика
Ответ на: комментарий от EvgGad_303

гашу сервант, вынимаю диски. Вставляю диски на горячую в другой сервант.
в другой сервант.
другое предназначение

старый пошел в утиль. Зачем еще нужен импорт пула кроме как переместить относительно новые диски с металлолома на свежий сервачок. Если дисков хоть жопой жуй, то пул и по сетке перелить можно.

стопорим все процессы эксплутирующие пул, делаю sync, экспортирую пул, гашу сервант.

а че экспортировать пул сразу с кучей пашуших виртуалок, без их предварительного стопора.

axelroot
()
Ответ на: комментарий от Sigizmund

Диски раньше использовались для экспериментов с dm-raid и, невзирая на то, что разделов рейда на них нет, он находил свои метки

припоминаю что тож сталкивался с нечто подобным.

axelroot
()
Ответ на: комментарий от axelroot

Зачем еще нужен импорт пула кроме как переместить относительно новые диски с металлолома на свежий сервачок.

А если подумать? хайлавайла, не?

EvgGad_303 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.