Правильное приготовление и работа с ZFS под FreeBSD

    Некоторое время назад возникла задача построения достаточно вместительного массива для хранения оперативных инкрементальных бекапов. Причём тратить деньги особо не хотелось, а место было нужно. Решение было простым и достаточно удобным. Далее много текста.


    За основу было взято шасси SuperChassis 825TQ-560LPB

    В которое было вставлено 8 дисков Hitachi 1TB и контроллер LSI Logic SAS HBA SAS3081E-R. Мы заранее планировали схему без аппаратного рейда опираясь только на возможности ZFS.

    Первая версия сервера на FreeBSD 7.2-STABLE прожила примерно около 3х месяцев, за это время отловились основные баги в виде ограничения используемой памяти vm.kmem_size и vfs.zfs.arc_max.
    При недостатке выделяемой ядру памяти система падала в панику, при недостатке буферов arc_max очень сильно падала скорость работы. Для загрузки системы использовалась флешка размером 1GB, которая позволила спокойно менять версию системы простой заменой флешки с новой сборкой.

    Схема построенного массива была основана на адресации по имени диска(устройства).
    Далее по тексту будут вставки из dmesg и консольных команд работы.
    mpt0: <LSILogic SAS/SATA Adapter> port 0x2000-0x20ff mem 0xdc210000-0xdc213fff,0xdc200000-0xdc20ffff irq 16 at device 0.0 on pci3
    mpt0: [ITHREAD]
    mpt0: MPI Version=1.5.20.0
    mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
    mpt0: 0 Active Volumes (2 Max)
    mpt0: 0 Hidden Drive Members (14 Max)

    da0 at mpt0 bus 0 scbus0 target 0 lun 0
    da0: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da0: 300.000MB/s transfers
    da0: Command Queueing enabled
    da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da1 at mpt0 bus 0 scbus0 target 1 lun 0
    da1: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da1: 300.000MB/s transfers
    da1: Command Queueing enabled
    da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da2 at mpt0 bus 0 scbus0 target 2 lun 0
    da2: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da2: 300.000MB/s transfers
    da2: Command Queueing enabled
    da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da3 at mpt0 bus 0 scbus0 target 3 lun 0
    da3: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da3: 300.000MB/s transfers
    da3: Command Queueing enabled
    da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da4 at mpt0 bus 0 scbus0 target 4 lun 0
    da4: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da4: 300.000MB/s transfers
    da4: Command Queueing enabled
    da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da5 at mpt0 bus 0 scbus0 target 5 lun 0
    da5: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da5: 300.000MB/s transfers
    da5: Command Queueing enabled
    da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da6 at mpt0 bus 0 scbus0 target 7 lun 0
    da6: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da6: 300.000MB/s transfers
    da6: Command Queueing enabled
    da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da7 at mpt0 bus 0 scbus0 target 8 lun 0
    da7: <ATA Hitachi HDE72101 A31B> Fixed Direct Access SCSI-5 device
    da7: 300.000MB/s transfers
    da7: Command Queueing enabled
    da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    ugen3.2: <JetFlash> at usbus3
    umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus3
    umass0: SCSI over Bulk-Only; quirks = 0x0100
    umass0:2:0:-1: Attached to scbus2
    da8 at umass-sim0 bus 0 scbus2 target 0 lun 0
    da8: <JetFlash Transcend 1GB 8.07> Removable Direct Access SCSI-2 device
    da8: 40.000MB/s transfers
    da8: 963MB (1972224 512 byte sectors: 64H 32S/T 963C)
    Trying to mount root from ufs:/dev/ufs/FBSDUSB

    В принципе всё более менее понятно. Есть контроллер, есть луны, есть диски, есть имена подключенных устройств к контроллеру.
    backupstorage# zpool create storage raidz da0 da1 da2 da3 da4 da5 da6 da7
    backupstorage# zpool status -v
      pool: storage
     state: ONLINE
     scrub: none requested
    config:
    
            NAME        STATE     READ WRITE CKSUM
            storage     ONLINE       0     0     0
              raidz1    ONLINE       0     0     0
                da0     ONLINE       0     0     0
                da1     ONLINE       0     0     0
                da2     ONLINE       0     0     0
                da3     ONLINE       0     0     0
                da4     ONLINE       0     0     0
                da5     ONLINE       0     0     0
                da6     ONLINE       0     0     0
                da7     ONLINE       0     0     0
    
    errors: No known data errors
    


    Всё работает до тех пор пока не умирает один из дисков. У меня начал осыпаться седьмой диск и контроллер по timeout выкидывал его из массива. Причём уверенности в том, что посыпался сам диск у меня не было, потому что диски были абсолютно новыми и никаким нагрузкам не подвергались.
    DFT от Hitachi ошибок не находила и говорила что всё в норме, только иногда подтормаживала. MHDD нашёл много секторов с временем доступа около 500 мс, после 50 таких секторов я диск просто поменял по гарантии.

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

    Проблема первая: Массив с нумерацией дисков не привязанной к лунам
    ZFS в Solaris разрабатывалась с учётом привязки дисков к номерам контроллеров и лунам на этих контроллерах. В случае использования такой схемы учёта необходимо только заменить умерший диск и синхронизировать данные в массиве. В FreeBSD как и в Linux именование устройств обычно идёт прозрачное и не зависит от физического порта на контроллере. В этом на самом деле и заключается самая большая засада.
    К примеру возьмём и вытащим из системы 5 диск, эмулируя аппаратный сбой на диске.
    backupstorage# camcontrol rescan all
    Re-scan of bus 0 was successful
    Re-scan of bus 1 was successful
    Re-scan of bus 2 was successful
    
    mpt0: mpt_cam_event: 0x16
    mpt0: mpt_cam_event: 0x12
    mpt0: mpt_cam_event: 0x16
    mpt0: mpt_cam_event: 0x16
    mpt0: mpt_cam_event: 0x16
    (da4:mpt0:0:4:0): lost device
    (da4:mpt0:0:4:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0
    (da4:mpt0:0:4:0): removing device entry
    
    backupstorage# zpool status -v
      pool: storage
     state: DEGRADED
     scrub: none requested
    config:
    
            NAME        STATE     READ WRITE CKSUM
            storage     DEGRADED     0     0     0
              raidz1    DEGRADED     0     0     0
                da0     ONLINE       0     0     0
                da1     ONLINE       0     0     0
                da2     ONLINE       0     0     0
                da3     ONLINE       0     0     0
                da4     REMOVED      0     0     0
                da5     ONLINE       0     0     0
                da6     ONLINE       0     0     0
                da7     ONLINE       0     0     0
    

    Всё отлично. Контроллер увидел, что у него пропал диск и пометил его как отсутствующий.
    Можно вставить новый диск и синхронизировать массив. НО если Вы перезагрузите сервер, то
    вас ждёт очень интересная картина(я уберу лишнюю информацию из квотинга dmesg, чтобы не перегружать текстом экран)
    da0 at mpt0 bus 0 scbus0 target 0 lun 0
    da0: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da1 at mpt0 bus 0 scbus0 target 1 lun 0
    da1: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da2 at mpt0 bus 0 scbus0 target 2 lun 0
    da2: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da3 at mpt0 bus 0 scbus0 target 3 lun 0
    da3: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da4 at mpt0 bus 0 scbus0 target 5 lun 0
    da4: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da5 at mpt0 bus 0 scbus0 target 7 lun 0
    da5: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    da6 at mpt0 bus 0 scbus0 target 8 lun 0
    da6: <ATA Hitachi HDE72101 A31B> Fixed Direct Access SCSI-5 device
    da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    SMP: AP CPU #1 Launched!
    GEOM: da0: the primary GPT table is corrupt or invalid.
    GEOM: da0: using the secondary instead -- recovery strongly advised.
    GEOM: da1: the primary GPT table is corrupt or invalid.
    GEOM: da1: using the secondary instead -- recovery strongly advised.
    GEOM: da2: the primary GPT table is corrupt or invalid.
    GEOM: da2: using the secondary instead -- recovery strongly advised.
    GEOM: da3: the primary GPT table is corrupt or invalid.
    GEOM: da3: using the secondary instead -- recovery strongly advised.
    GEOM: da4: the primary GPT table is corrupt or invalid.
    GEOM: da4: using the secondary instead -- recovery strongly advised.
    GEOM: da5: the primary GPT table is corrupt or invalid.
    GEOM: da5: using the secondary instead -- recovery strongly advised.
    GEOM: da6: the primary GPT table is corrupt or invalid.
    GEOM: da6: using the secondary instead -- recovery strongly advised.
    ugen3.2: <JetFlash> at usbus3
    umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus3
    umass0: SCSI over Bulk-Only; quirks = 0x0100
    umass0:2:0:-1: Attached to scbus2
    da7 at umass-sim0 bus 0 scbus2 target 0 lun 0
    da7: <JetFlash Transcend 1GB 8.07> Removable Direct Access SCSI-2 device
    da7: 40.000MB/s transfers
    da7: 963MB (1972224 512 byte sectors: 64H 32S/T 963C)
    Trying to mount root from ufs:/dev/ufs/FBSDUSB
    GEOM: da4: the primary GPT table is corrupt or invalid.
    GEOM: da4: using the secondary instead -- recovery strongly advised.
    GEOM: da5: the primary GPT table is corrupt or invalid.
    GEOM: da5: using the secondary instead -- recovery strongly advised.
    GEOM: da0: the primary GPT table is corrupt or invalid.
    GEOM: da0: using the secondary instead -- recovery strongly advised.
    GEOM: da1: the primary GPT table is corrupt or invalid.
    GEOM: da1: using the secondary instead -- recovery strongly advised.
    GEOM: da2: the primary GPT table is corrupt or invalid.
    GEOM: da2: using the secondary instead -- recovery strongly advised.
    GEOM: da3: the primary GPT table is corrupt or invalid.
    GEOM: da3: using the secondary instead -- recovery strongly advised.
    GEOM: da6: the primary GPT table is corrupt or invalid.
    GEOM: da6: using the secondary instead -- recovery strongly advised.
    GEOM: da4: the primary GPT table is corrupt or invalid.
    GEOM: da4: using the secondary instead -- recovery strongly advised.

    Что мы видим?
    Мы видим что по сравнению с первым дампом dmesg, устройств стало 8 вместо 9 и флешка стала da7 вместо da8. ZFS начинает материться о том, что есть проблемы с чтением GPT меток и что всё плохо.
    Zpool тупо развалился на глазах, так как нумерация дисков уехала на 1 вверх, что в свою очередь вызвало потерю массивом ориентиров для работы и путанице в метках дисков.
    backupstorage# zpool status -v
      pool: storage
     state: UNAVAIL
    status: One or more devices could not be used because the label is missing
            or invalid.  There are insufficient replicas for the pool to continue
            functioning.
    action: Destroy and re-create the pool from a backup source.
       see: http://www.sun.com/msg/ZFS-8000-5E
     scrub: none requested
    config:
    
            NAME        STATE     READ WRITE CKSUM
            storage     UNAVAIL      0     0     0  insufficient replicas
              raidz1    UNAVAIL      0     0     0  insufficient replicas
                da0     ONLINE       0     0     0
                da1     ONLINE       0     0     0
                da2     ONLINE       0     0     0
                da3     ONLINE       0     0     0
                da4     FAULTED      0     0     0  corrupted data
                da5     FAULTED      0     0     0  corrupted data
                da6     FAULTED      0     0     0  corrupted data
                da6     ONLINE       0     0     0
    

    Обратите внимание, что у нас 2!!! диска da6. Всё это потому, что у нас есть физический диск определенный как da6 и присутствует GPT метка da6 на диске который раньше был da6.

    теперь попробуем воткнуть диск который вытащили.
    backupstorage# camcontrol rescan all
    Re-scan of bus 0 was successful
    Re-scan of bus 1 was successful
    Re-scan of bus 2 was successful

    da8 at mpt0 bus 0 scbus0 target 4 lun 0
    da8: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da8: 300.000MB/s transfers
    da8: Command Queueing enabled
    da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    GEOM: da8: the primary GPT table is corrupt or invalid.
    GEOM: da8: using the secondary instead -- recovery strongly advised.

    Диск определился, но стал da8. Мы конечно же можем попробовать перестроить массив, но ни к чему хорошему это не приведёт. Поэтому просто перегружаемся.
    backupstorage# zpool status -v
      pool: storage
     state: ONLINE
     scrub: none requested
    config:
    
            NAME        STATE     READ WRITE CKSUM
            storage     ONLINE       0     0     0
              raidz1    ONLINE       0     0     0
                da0     ONLINE       0     0     0
                da1     ONLINE       0     0     0
                da2     ONLINE       0     0     0
                da3     ONLINE       0     0     0
                da4     ONLINE       0     0     0
                da5     ONLINE       0     0     0
                da6     ONLINE       0     0     0
                da7     ONLINE       0     0     0
    
    errors: No known data errors
    


    После перезагрузки zfs спокойно находит все диски, немного ругается в лог и продолжает работать.

    GEOM: da0: the primary GPT table is corrupt or invalid.
    GEOM: da0: using the secondary instead -- recovery strongly advised.
    GEOM: da1: the primary GPT table is corrupt or invalid.
    GEOM: da1: using the secondary instead -- recovery strongly advised.
    GEOM: da2: the primary GPT table is corrupt or invalid.
    GEOM: da2: using the secondary instead -- recovery strongly advised.
    GEOM: da3: the primary GPT table is corrupt or invalid.
    GEOM: da3: using the secondary instead -- recovery strongly advised.
    GEOM: da4: the primary GPT table is corrupt or invalid.
    GEOM: da4: using the secondary instead -- recovery strongly advised.
    GEOM: da5: the primary GPT table is corrupt or invalid.
    GEOM: da5: using the secondary instead -- recovery strongly advised.
    GEOM: da6: the primary GPT table is corrupt or invalid.
    GEOM: da6: using the secondary instead -- recovery strongly advised.
    GEOM: da7: the primary GPT table is corrupt or invalid.
    GEOM: da7: using the secondary instead -- recovery strongly advised.
    GEOM: da0: the primary GPT table is corrupt or invalid.
    GEOM: da0: using the secondary instead -- recovery strongly advised.
    GEOM: da2: the primary GPT table is corrupt or invalid.
    GEOM: da2: using the secondary instead -- recovery strongly advised.
    GEOM: da7: the primary GPT table is corrupt or invalid.
    GEOM: da7: using the secondary instead -- recovery strongly advised.

    resilver проходит практически безболезненно, так как у нас не было работы с данными на сломанном массиве.
    GEOM: da0: the primary GPT table is corrupt or invalid.
    GEOM: da0: using the secondary instead -- recovery strongly advised.
    GEOM: da3: the primary GPT table is corrupt or invalid.
    GEOM: da3: using the secondary instead -- recovery strongly advised.
    ====================
    
    backupstorage# zpool status -v
      pool: storage
     state: ONLINE
     scrub: resilver completed after 0h0m with 0 errors on Wed Nov 25 11:06:15 2009
    config:
    
            NAME        STATE     READ WRITE CKSUM
            storage     ONLINE       0     0     0
              raidz1    ONLINE       0     0     0
                da0     ONLINE       0     0     0
                da1     ONLINE       0     0     0
                da2     ONLINE       0     0     0  512 resilvered
                da3     ONLINE       0     0     0  512 resilvered
                da4     ONLINE       0     0     0
                da5     ONLINE       0     0     0
                da6     ONLINE       0     0     0  512 resilvered
                da7     ONLINE       0     0     0  512 resilvered
    
    errors: No known data errors
    

    В общем мы убедились, что такая схема не очень надёжна при автоматической нумерации дисков в контроллере. Хотя если количество дисков не меняется — их можно переставлять в произвольном порядке. Массив будет работать исправно.

    Проблема вторая: geomlabel на дисках.
    Дабы попытаться решить проблему с именованием дисков было решено попробовать пометить их метками и уже метки добавить в массив. При создании метки на диске — она пишется в конец диска, при инициализации диска система считывает метки и создаёт виртуальные устройства /dev/label/имяметки.
    backupstorage# zpool create storage raidz label/disk0 label/disk1 label/disk2 label/disk3 label/disk4 label/disk5 label/disk6 label/disk7
    backupstorage# zpool status -v
      pool: storage
     state: ONLINE
     scrub: none requested
    config:
    
            NAME             STATE     READ WRITE CKSUM
            storage          ONLINE       0     0     0
              raidz1         ONLINE       0     0     0
                label/disk0  ONLINE       0     0     0
                label/disk1  ONLINE       0     0     0
                label/disk2  ONLINE       0     0     0
                label/disk3  ONLINE       0     0     0
                label/disk4  ONLINE       0     0     0
                label/disk5  ONLINE       0     0     0
                label/disk6  ONLINE       0     0     0
                label/disk7  ONLINE       0     0     0
    
    errors: No known data errors
    backupstorage# ls /dev/label/disk*
    /dev/label/disk0        /dev/label/disk2        /dev/label/disk4        /dev/label/disk6
    /dev/label/disk1        /dev/label/disk3        /dev/label/disk5        /dev/label/disk7
    

    Массив живёт нормально, теперь мы выдёргиваем disk1 и откладываем в сторону.

    Перегружаем сервер и смотрим в лог.
    GEOM: da0: corrupt or invalid GPT detected.
    GEOM: da0: GPT rejected -- may not be recoverable.
    GEOM: da1: corrupt or invalid GPT detected.
    GEOM: da1: GPT rejected -- may not be recoverable.
    GEOM: da2: corrupt or invalid GPT detected.
    GEOM: da2: GPT rejected -- may not be recoverable.
    GEOM: da3: corrupt or invalid GPT detected.
    GEOM: da3: GPT rejected -- may not be recoverable.
    GEOM: da4: corrupt or invalid GPT detected.
    GEOM: da4: GPT rejected -- may not be recoverable.
    GEOM: da5: corrupt or invalid GPT detected.
    GEOM: da5: GPT rejected -- may not be recoverable.
    GEOM: da6: corrupt or invalid GPT detected.
    GEOM: da6: GPT rejected -- may not be recoverable.
    GEOM: label/disk0: corrupt or invalid GPT detected.
    GEOM: label/disk0: GPT rejected -- may not be recoverable.
    GEOM: label/disk2: corrupt or invalid GPT detected.
    GEOM: label/disk2: GPT rejected -- may not be recoverable.
    GEOM: label/disk3: corrupt or invalid GPT detected.
    GEOM: label/disk3: GPT rejected -- may not be recoverable.
    GEOM: label/disk4: corrupt or invalid GPT detected.
    GEOM: label/disk4: GPT rejected -- may not be recoverable.
    GEOM: label/disk5: corrupt or invalid GPT detected.
    GEOM: label/disk5: GPT rejected -- may not be recoverable.
    GEOM: label/disk6: corrupt or invalid GPT detected.
    GEOM: label/disk6: GPT rejected -- may not be recoverable.
    GEOM: label/disk7: corrupt or invalid GPT detected.
    GEOM: label/disk7: GPT rejected -- may not be recoverable.
    da7 at umass-sim0 bus 0 scbus2 target 0 lun 0
    da7: <JetFlash Transcend 1GB 8.07> Removable Direct Access SCSI-2 device
    da7: 40.000MB/s transfers
    da7: 963MB (1972224 512 byte sectors: 64H 32S/T 963C)
    Trying to mount root from ufs:/dev/ufs/FBSDUSB
    GEOM: da0: corrupt or invalid GPT detected.
    GEOM: da0: GPT rejected -- may not be recoverable.
    GEOM: da1: corrupt or invalid GPT detected.
    GEOM: da1: GPT rejected -- may not be recoverable.
    GEOM: label/disk2: corrupt or invalid GPT detected.
    GEOM: label/disk2: GPT rejected -- may not be recoverable.
    GEOM: da2: corrupt or invalid GPT detected.
    GEOM: da2: GPT rejected -- may not be recoverable.
    GEOM: label/disk3: corrupt or invalid GPT detected.
    GEOM: label/disk3: GPT rejected -- may not be recoverable.
    GEOM: da3: corrupt or invalid GPT detected.
    GEOM: da3: GPT rejected -- may not be recoverable.
    GEOM: label/disk4: corrupt or invalid GPT detected.
    GEOM: label/disk4: GPT rejected -- may not be recoverable.
    GEOM: da4: corrupt or invalid GPT detected.
    GEOM: da4: GPT rejected -- may not be recoverable.
    GEOM: label/disk5: corrupt or invalid GPT detected.
    GEOM: label/disk5: GPT rejected -- may not be recoverable.
    GEOM: da5: corrupt or invalid GPT detected.
    GEOM: da5: GPT rejected -- may not be recoverable.
    

    Но при всей ругани массив на поверку оказывается живой. с живой структурой и статусом DEGRADED, что намного лучше чем в первом случае.
    backupstorage# zpool status
      pool: storage
     state: DEGRADED
    status: One or more devices has experienced an unrecoverable error.  An
            attempt was made to correct the error.  Applications are unaffected.
    action: Determine if the device needs to be replaced, and clear the errors
            using 'zpool clear' or replace the device with 'zpool replace'.
       see: http://www.sun.com/msg/ZFS-8000-9P
     scrub: none requested
    config:
    
            NAME             STATE     READ WRITE CKSUM
            storage          DEGRADED     0     0     0
              raidz1         DEGRADED     0     0     0
                label/disk0  ONLINE       0     0     0
                label/disk1  REMOVED      0    94     0
                label/disk2  ONLINE       0     0     0
                label/disk3  ONLINE       0     0     0
                label/disk4  ONLINE       0     0     0
                label/disk5  ONLINE       0     0     0
                label/disk6  ONLINE       0     0     0
                label/disk7  ONLINE       0     0     0
    
    errors: No known data errors
    ====================
    

    Теперь мы зануляем диск который мы вытащили и вставим его обратно в систему.
    Метка на диске записана в самом конце диска, поэтому штатное зануление начала диска нам ничем не поможет. придётся или нулить конец или просто диск целиком. Всё зависит от наличия у вас времени.
    mpt0: mpt_cam_event: 0x16
    mpt0: mpt_cam_event: 0x12
    mpt0: mpt_cam_event: 0x16
    da8 at mpt0 bus 0 scbus0 target 1 lun 0
    da8: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device
    da8: 300.000MB/s transfers
    da8: Command Queueing enabled
    da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
    

    Даём новому диску метку «disk8» и пытаемся заменить «умерший» диск новым.
    backupstorage# ls /dev/label/
    disk0   disk2   disk3   disk4   disk5   disk6   disk7   disk8
    
    backupstorage# zpool replace storage label/disk1 label/disk8
    cannot replace label/disk1 with label/disk8: label/disk8 is busy
    backupstorage# zpool replace -f storage label/disk1 label/disk8
    cannot replace label/disk1 with label/disk8: label/disk8 is busy
    

    Система отказывается менять нам диск ссылаясь на его занятость. Заменить «умерший» диск можно только прямым именем устройства. Почему так сделано, я до конца не понял. Отбрасываем затею замены меток на новом диске и пробуем просто дать метку «disk1» новому диску.
    backupstorage# glabel label disk1 da8
    

    Теперь нам нужно сказать, что диск у нас вернулся в строй.
    backupstorage# zpool online storage label/disk1
    backupstorage# zpool status
      pool: storage
     state: ONLINE
    status: One or more devices has experienced an unrecoverable error.  An
            attempt was made to correct the error.  Applications are unaffected.
    action: Determine if the device needs to be replaced, and clear the errors
            using 'zpool clear' or replace the device with 'zpool replace'.
       see: http://www.sun.com/msg/ZFS-8000-9P
     scrub: resilver completed after 0h0m with 0 errors on Wed Nov 25 18:29:17 2009
    config:
    
            NAME             STATE     READ WRITE CKSUM
            storage          ONLINE       0     0     0
              raidz1         ONLINE       0     0     0
                label/disk0  ONLINE       0     0     0  6.50K resilvered
                label/disk1  ONLINE       0    94     1  10.5K resilvered
                label/disk2  ONLINE       0     0     0  6K resilvered
                label/disk3  ONLINE       0     0     0  3.50K resilvered
                label/disk4  ONLINE       0     0     0  6.50K resilvered
                label/disk5  ONLINE       0     0     0  6.50K resilvered
                label/disk6  ONLINE       0     0     0  5.50K resilvered
                label/disk7  ONLINE       0     0     0  3K resilvered
    
    errors: No known data errors
    

    Всё встаёт на свои места и после синхронизации можно сбросить статус пула на нормальный.
    А вот тут начинается проблема. Так как метка диска сделанная glabel пишется в конец диска, то zfs в принципе не знает ничего о том, где она записана. И при полном заполнении диска перетирает эту метку. Диску в массиве присваивается физическое имя и мы возвращаемся к пункту 1 наших проблем.

    Решение проблемы
    Решение проблемы оказалось немного банальным и простым. Давным давно FreeBSD стала уметь делать GPT разделы на дисках больших объёмов. В FreeBSD 7.2 именование GPT разделов не работало и доступ к ним осуществлялся по прямому имени устройства /dev/da0p1(пример для первой партиции GPT)
    В FreeBSD 8.0 в систему GPT меток было внесено изменение. И теперь GPT разделы можно именовать и обращаться к ним как к виртуальным устройствам через /dev/gpt/меткараздела.

    Всё что нам реально необходимо сделать — это проименовать разделы на дисках и собрать из них массив. Как это сделать написано в ZFS Boot Howto которое очень быстро гуглится.
    backupstorage# gpart create -s GPT ad0
    backupstorage# gpart add -b 34 -s 1953525101 -i 1 -t freebsd-zfs -l disk0 ad0
    backupstorage# gpart show
    =>        34  1953525101  da0  GPT  (932G)
              34  1953525101    1  freebsd-zfs  (932G)
    backupstorage# gpart show -l
    =>        34  1953525101  da0  GPT  (932G)
              34  1953525101    1  disk0  (932G)
    backupstorage# ls /dev/gpt
    disk0
    

    После создания GPT раздела по gpart show можно посмотреть где начинается и где заканчивается область данных на диске. Далее мы создаём этот раздел и даём ему метку «disk0».
    Проделываем эту операцию для всех дисков в системе и собираем из полученных разделов массив.
    backupstorage# zpool status -v
      pool: storage
     state: ONLINE
     scrub: none requested
    config:
    
            NAME           STATE     READ WRITE CKSUM
            storage        ONLINE       0     0     0
              raidz1       ONLINE       0     0     0
                gpt/disk0  ONLINE       0     0     0
                gpt/disk1  ONLINE       0     0     0
                gpt/disk2  ONLINE       0     0     0
                gpt/disk3  ONLINE       0     0     0
                gpt/disk4  ONLINE       0     0     0
                gpt/disk5  ONLINE       0     0     0
                gpt/disk6  ONLINE       0     0     0
                gpt/disk7  ONLINE       0     0     0
    
    errors: No known data errors
    

    Сервер спокойно переживает любые перезагрузки и перестановку дисков, а также их замену с той-же меткой. Скорость работы данного массива по сети достигает 70-80 мегабайт в секунду. Локальная скорость записи на массив в зависимости от заполняемости буферов доходит до 200 мегабайт в секунду.

    PS: при использовании gpt меток натолкнулся на странный глюк, что система не видела новую метку на диске, но потом это само собой прошло.
    PPS: энтузиастам которые пробуют запустить FreeBSD 8.0 с флешки(если это еще не починили) — пригодится вот такой dirty hack.
    Index: sys/kern/vfs_mount.c
    ===================================================================
    RCS file: /home/ncvs/src/sys/kern/vfs_mount.c,v
    retrieving revision 1.308
    diff -u -r1.308 vfs_mount.c
    --- sys/kern/vfs_mount.c 5 Jun 2009 14:55:22 -0000 1.308
    +++ sys/kern/vfs_mount.c 29 Sep 2009 17:08:25 -0000
    @@ -1645,6 +1645,9 @@
    options = NULL;
    + /* NASTY HACK: wait for USB sticks to appear */
    + pause("usbhack", hz * 10);
    +
    root_mount_prepare();
    mount_zone = uma_zcreate("Mountpoints", sizeof(struct mount),

    В новом USB стеке при загрузке ядра USB устройства не всегда определяются вовремя и возникает ошибка при монтировании разделов системы.
    Данный хак выставляет в системе таймаут в 10 секунд для ожидания готовности USB накопителя.

    PPPS: если будут вопросы — задавайте.

    Настройки loader.conf для машины с 2мя гигабайтами памяти.
    vm.kmem_size=«1536M»
    vm.kmem_size_max=«1536M»
    vfs.zfs.arc_max=«384M»


    © Aborche 2009
    Поделиться публикацией

    Комментарии 45

      0
      Интересно, если сервер изначально планировался как backup storage для чего извращаться с BSD. Для таких задач лучше использовать open-e или openNAS.
      Например список фич бесплатной версии Open-e:
      www.open-e.com/products/open-e-dss-v6-lite/features/
        +1
        А она умеет рулить массивом из 22Тб, в случае если он должен быть доступен по одной точке монтирования?
        Как я понимаю тут либо zfs, либо ничего.
        Или я ошибаюсь?
        +1
        знаем, щупали. во-первых open-e пропиетарщина, соотв. что в админку засунули то и умеет. помнится нужно было сильно DFS поднять так выкусите…

        а ZFS сравнивать со всем остальным — как мерседес с жигулями. Во фре конечно с бубнами заводится, лучше солярку, но всё равно рад за них.
        0
        The Open-E Data Storage Software V6 Lite (DSS V6 Lite)
        is a FREE version of Open-E DSS V6 delivering unified file and block storage management operating system (OS) with Network Attached Storage (NAS) and Storage Area Network (SAN) functionality.

        In order to evaluate free product, licensed for 2TB of storage simply register and download at our portal and get up to 10 versions at a time!

        У меня как минимум 7 тер получилось. Тоже самое можно было сделать на OpenSolaris, но смысла городить огород ради одной машины нет. Тем более мне нужно было очень гибко разнести возможности доступа к этой машине для разных серверов.
          0
          Понимаю, своя сорочка ближе к телу.
          Если Вам прикрутить failover контроллеров и multipath(можно GEOM'ый), добавить простенький web/cli management — можна будет и продавать такие железки для виндовых сеток. Задумайтесь :)
          0
          Огромное спасибо за статью! вопрос — скорость передачи данных по сети 70-80 мегабайт в секунду — по какому протоколу?
            +1
            samba :) Если правильно затюнить буфера samba вместе с буферами windows, то скорость будет очень высокой.
              +1
              только буферы самбы и виндоуз, а буферы FreeBSD? поделитесь рецептом, я сколько ни тюнил больше 40 метров в секунду не выжимал, правда на UFS.
                +1
                Присоединяюсь к просьбе.
                  +2
                  Винду тюнил по вот этим двум книжкам.
                  www.redbooks.ibm.com/redpapers/pdfs/redp3943.pdf
                  www.redbooks.ibm.com/redbooks/pdfs/sg245287.pdf

                  Буфера Samba тюнил из расчёта уменьшения фрагментации пакетов и кратности буферов приёма-передачи размеру mss=1460 (mtu — 40 байт заголовка).
                  Буфера FreeBSD тюнил подбором параметров

                  net.inet.tcp.recvspace=32768
                  net.inet.tcp.recvbuf_auto=0
                  net.inet.tcp.recvbuf_inc=16384

                  net.inet.tcp.sendspace=32768
                  net.inet.tcp.sendbuf_auto=0
                  net.inet.tcp.sendbuf_inc=16384
              –1
              В новой версии FreeBSD по умолчанию:
              > uname -rsm
              FreeBSD 8.0-STABLE amd64
              > sysctl vm.kmem_size
              vm.kmem_size: 1334964224
              > sysctl vm.kmem_size_max
              vm.kmem_size_max: 329853485875
              > sysctl vfs.zfs.arc_max
              vfs.zfs.arc_max: 834352640

              В FreeBSD 7.2-STABLE именование GPT разделов заработало — именно таким образом я осуществил переход с 7.2 на 8.0-BETA-2 и далее благополучно обновился до 8.0-STABLE.
                +2
                ахренеть! респект! /me пошел перестраивать свои хранилища! 2гб оперативки теперь хватает для zfs? раньше юешено все тупило у меня при таком раскладе.
                ну и самый банальный вопрос рабоатет ли iscsi? Пробывали вы по nfs делать доступ?
                  0
                  Нативного iscsi для zfs как в Solaris во фре нет.
                    0
                    нативного iSCSI и в солярке нет. сан и сочуствующие сами рекомендуют юзать COMSTAR а не то тормознутое поделие что прилагается.
                    0
                    iscsi тома можно сделать из файлов. я надеюсь таки smbshare и iscsi share перенесут на FreeBSD со временем.
                      0
                      надеюсь, мне помню chflag не хватало в 7 версии пула;
                    +2
                    огромное спасибо за статью. Сам собираюсь пройти через эти дебри, правда квалификации пока не хватает. Вопрос: есть ли опыт поставить FreeBSD на ZFS зеркало(чтобы защитить саму систему), если да, то какой метод использовали
                      +1
                      Я ставил 8.0-STABLE на зеркало по методу описанному на офф сайте.
                      Основная проблема была в том, что после создания zraid система при копировании файлов для установки постоянно падала в панику. Победилось копированием небольшими кусками. Ну и последующей сборкой ядра с KVA_PAGES=512 и установкой при загрузке указанных в статье параметров.
                      В итоге получилось следующее:

                      # gpart show
                      => 34 3900682173 aacd0 GPT (1.8T)
                      34 128 1 freebsd-boot (64K)
                      162 8388608 2 freebsd-swap (4.0G)
                      8388770 3892293437 3 freebsd-zfs (1.8T)

                      => 34 3900682173 aacd1 GPT (1.8T)
                      34 128 1 freebsd-boot (64K)
                      162 8388608 2 freebsd-swap (4.0G)
                      8388770 3892293437 3 freebsd-zfs (1.8T)

                      => 34 3900682173 aacd2 GPT (1.8T)
                      34 128 1 freebsd-boot (64K)
                      162 8388608 2 freebsd-swap (4.0G)
                      8388770 3892293437 3 freebsd-zfs (1.8T)

                      # zpool status
                      pool: zroot
                      state: ONLINE
                      scrub: none requested
                      config:

                      NAME STATE READ WRITE CKSUM
                      zroot ONLINE 0 0 0
                      raidz1 ONLINE 0 0 0
                      gpt/disk0 ONLINE 0 0 0
                      gpt/disk1 ONLINE 0 0 0
                      gpt/disk2 ONLINE 0 0 0

                      errors: No known data errors
                        0
                        Выше не правильно указал систему, должна быть такая:
                        #uname -a
                        FreeBSD xxxxx 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Nov 26 18:25:36 MSK 2009 root@:/usr/obj/usr/src/sys/ZFSTUNE i386
                      0
                      Пользуясь моментом (в этой теме собралось много нужно-умных людей):
                      — Народ, подскажите плиз, что лучше всего использовать для распределенного файлового хранилища?

                      Имеем:
                      — 6 серверов с Linux'ом,
                      — гигабитный 3COM свитч 4200G

                      Задача:
                      — отдача тучи картинок (размер от 3kb до 5mb) по http (желательно чтобы каждый этот сервер мог выступать в роли фронтенда отдачи картинок)
                      — возможность выхода из строя 1-2 серверов
                      — минимальное вмешательство в администрирование

                      Хотим попробовать GlusterFS, стоит он внимания или надо посмотреть на что-нибудь другое?

                        +1
                        Использовал GlusterFS для подобной задачи года полтора назад. В результате оказалось проще и быстрее ранжировать картинки по группам серверов, upload новых картинок отселиживался inotify, далее скрипт делал rsync на все сервера нужной нам группы.
                          0
                          wiki.lustre.org/index.php/Main_Page

                          Но не знаю как там с доступом к отдельным серверам — вроде все через meta сервера делается
                            0
                            Для продакшин наверное это пока не дозрело, но вы туда написали.
                            LustreFS (Orion) over ZFS и всё в опенсорсе, звучит заманчиво?

                            А если вы задумались над чем-то серёзным, то не изобретайте велосипед, купите нормальную СХД.
                            0
                            >ZFS в Solaris разрабатывалась с учётом привязки дисков к номерам контроллеров и лунам на этих контроллерах.

                            и тут обманываешь людей :) ну вчера же проверяли на солярке. диски можно перетусовать местами, даже по разным контроллерам рассовать, всё равно шайтан найдет.
                              0
                              ну значит правильно метит GPT.
                              Вот дамп с версии с gpt разделами

                              backupstorage# zdb
                              storage
                                  version=13
                                  name='storage'
                                  state=0
                                  txg=2949
                                  pool_guid=5702684262929827531
                                  hostid=2532654325
                                  hostname=''
                                  vdev_tree
                                      type='root'
                                      id=0
                                      guid=5702684262929827531
                                      children[0]
                                              type='raidz'
                                              id=0
                                              guid=10462951798981416329
                                              nparity=1
                                              metaslab_array=23
                                              metaslab_shift=36
                                              ashift=9
                                              asize=8001599569920
                                              is_log=0
                                              children[0]
                                                      type='disk'
                                                      id=0
                                                      guid=3783332541596737231
                                                      path='/dev/gpt/disk0'
                                                      whole_disk=0
                                                      DTL=35
                                              children[1]
                                                      type='disk'
                                                      id=1
                                                      guid=17895466354873902474
                                                      path='/dev/gpt/disk1'
                                                      whole_disk=0
                                                      DTL=34
                                              children[2]
                                                      type='disk'
                                                      id=2
                                                      guid=17183354981381863742
                                                      path='/dev/gpt/disk2'
                                                      whole_disk=0
                                                      DTL=33
                                              children[3]
                                                      type='disk'
                                                      id=3
                                                      guid=15309789136672692046
                                                      path='/dev/gpt/disk3'
                                                      whole_disk=0
                                                      DTL=32
                                              children[4]
                                                      type='disk'
                                                      id=4
                                                      guid=11995812205645754507
                                                      path='/dev/gpt/disk4'
                                                      whole_disk=0
                                                      DTL=31
                                              children[5]
                                                      type='disk'
                                                      id=5
                                                      guid=6063459237322854932
                                                      path='/dev/gpt/disk5'
                                                      whole_disk=0
                                                      DTL=30
                                              children[6]
                                                      type='disk'
                                                      id=6
                                                      guid=8145092386428344189
                                                      path='/dev/gpt/disk6'
                                                      whole_disk=0
                                                      DTL=29
                                              children[7]
                                                      type='disk'
                                                      id=7
                                                      guid=9189182978871328496
                                                      path='/dev/gpt/disk7'
                                                      whole_disk=0
                                                      DTL=28
                              


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

                              prmedia# zdb
                              storage
                                  version=6
                                  name='storage'
                                  state=0
                                  txg=4
                                  pool_guid=13934529001025246287
                                  hostid=1760528258
                                  hostname=''
                                  vdev_tree
                                      type='root'
                                      id=0
                                      guid=13934529001025246287
                                      children[0]
                                              type='raidz'
                                              id=0
                                              guid=2084574688071794880
                                              nparity=1
                                              metaslab_array=14
                                              metaslab_shift=32
                                              ashift=9
                                              asize=6001188143104
                                              children[0]
                                                      type='disk'
                                                      id=0
                                                      guid=13825419530404204466
                                                      path='/dev/ad4'
                                                      devid='ad:9VS0P65J'
                                                      whole_disk=0
                                              children[1]
                                                      type='disk'
                                                      id=1
                                                      guid=8367710449844254185
                                                      path='/dev/ad6'
                                                      devid='ad:9VS0F68M'
                                                      whole_disk=0
                                              children[2]
                                                      type='disk'
                                                      id=2
                                                      guid=8977960755063011626
                                                      path='/dev/ad8'
                                                      devid='ad:9VS01BGV'
                                                      whole_disk=0
                                              children[3]
                                                      type='disk'
                                                      id=3
                                                      guid=14908048518443631010
                                                      path='/dev/ad10'
                                                      devid='ad:9VS0P4HF'
                                                      whole_disk=0
                              


                              Вот еще с одной машины привязка.

                              $ zdb
                              smbss
                                  version=13
                                  name='smbss'
                                  state=0
                                  txg=236161
                                  pool_guid=17217239028423194874
                                  hostid=4247501507
                                  hostname=''
                                  vdev_tree
                                      type='root'
                                      id=0
                                      guid=17217239028423194874
                                      children[0]
                                              type='raidz'
                                              id=0
                                              guid=10166525209374749218
                                              nparity=1
                                              metaslab_array=23
                                              metaslab_shift=32
                                              ashift=9
                                              asize=1399966138368
                                              is_log=0
                                              children[0]
                                                      type='disk'
                                                      id=0
                                                      guid=8564838834527224646
                                                      path='/dev/ad1'
                                                      whole_disk=0
                                                      DTL=80
                                              children[1]
                                                      type='disk'
                                                      id=1
                                                      guid=11770771462512284556
                                                      path='/dev/ad2'
                                                      whole_disk=0
                                                      DTL=79
                                              children[2]
                                                      type='disk'
                                                      id=2
                                                      guid=13668376697090075723
                                                      path='/dev/ad3'
                                                      whole_disk=0
                                                      DTL=78
                                              children[3]
                                                      type='disk'
                                                      id=3
                                                      guid=13300081630264141124
                                                      path='/dev/ad4'
                                                      whole_disk=0
                                                      DTL=77
                                              children[4]
                                                      type='disk'
                                                      id=4
                                                      guid=11183167337133163969
                                                      path='/dev/ad5'
                                                      whole_disk=0
                                                      DTL=76
                                              children[5]
                                                      type='disk'
                                                      id=5
                                                      guid=3010502291483550599
                                                      path='/dev/ad6'
                                                      whole_disk=0
                                                      DTL=75
                                              children[6]
                                                      type='disk'
                                                      id=6
                                                      guid=12858632936445829678
                                                      path='/dev/ad7'
                                                      whole_disk=0
                                                      DTL=81
                              


                              называется почуйствуйте разницу.
                                0
                                в солярке есть из коробки devid вида 'id1,sd@n600605b000965e40129da3040c725e27/a', которое походу не меняется при перестановке дисков. плюс как уже выяснили, 8мб раздел на каждом zpool-устройстве с внутренней инфой.

                                в общем подход весьма похож, разница что из коробки да и всё. в фре тоже со временем поправят )
                                  0
                                  zdb
                                  stor
                                  version=14
                                  name='stor'
                                  state=0
                                  txg=67576
                                  pool_guid=1318916582355966918
                                  hostid=4535124
                                  hostname='lab-stor1'
                                  vdev_tree
                                  type='root'
                                  id=0
                                  guid=1318916582355966918
                                  children[0]
                                  type='raidz'
                                  id=0
                                  guid=17092437658460011700
                                  nparity=1
                                  metaslab_array=23
                                  metaslab_shift=36
                                  ashift=9
                                  asize=9994928128000
                                  is_log=0
                                  children[0]
                                  type='disk'
                                  id=0
                                  guid=7266466392856570407
                                  path='/dev/dsk/c7t4d0s0'
                                  devid='id1,sd@n600605b000965e401281d6da26c71a1b/a'
                                  phys_path='/pci@0,0/pci8086,29f9@6/pci1000,1013@0/sd@4,0:a'
                                  whole_disk=1
                                  DTL=44
                                  children[1]
                                  type='disk'
                                  id=1
                                  guid=5382680510957273142
                                  path='/dev/dsk/c7t1d0s0'
                                  devid='id1,sd@n600605b000965e40129da3040c7d071f/a'
                                  phys_path='/pci@0,0/pci8086,29f9@6/pci1000,1013@0/sd@1,0:a'
                                  whole_disk=1
                                  DTL=43
                                  children[2]
                                  type='disk'
                                  id=2
                                  guid=5634230046170865273
                                  path='/dev/dsk/c7t2d0s0'
                                  devid='id1,sd@n600605b000965e40129da3050c891253/a'
                                  phys_path='/pci@0,0/pci8086,29f9@6/pci1000,1013@0/sd@2,0:a'
                                  whole_disk=1
                                  DTL=42
                                  children[3]
                                  type='disk'
                                  id=3
                                  guid=1867088018747561587
                                  path='/dev/dsk/c7t3d0s0'
                                  devid='id1,sd@n600605b000965e40129da3060c95c8e1/a'
                                  phys_path='/pci@0,0/pci8086,29f9@6/pci1000,1013@0/sd@3,0:a'
                                  whole_disk=1
                                  DTL=41
                                  children[4]
                                  type='disk'
                                  id=4
                                  guid=1717292210218627046
                                  path='/dev/dsk/c7t0d0s0'
                                  devid='id1,sd@n600605b000965e40129da3040c725e27/a'
                                  phys_path='/pci@0,0/pci8086,29f9@6/pci1000,1013@0/sd@0,0:a'
                                  whole_disk=1
                                  DTL=40
                                    0
                                    ну теперь в принципе понятно почему в Solaris проблем с дисками нету как таковых. Идентификатор устройства + привязка на партицию.
                                0
                                Насколько я помню для соляры в таких случаях есть export/import. А как с ним на фре? Не пробовали?
                                  0
                                  есть. чудесно работает. до тех пор пока массив не развалится таким образом :)
                                    0
                                    Ну тогда может делать export когда вылетает диск и делать import когда он появляется?

                                    Хотя наверно тогда придется добавлять-удалять диски… Но по крайней мере он не должен развалитсья
                                  0
                                  А такой вопрос. Почему именно ZFS?

                                  Это в контексте «Мы заранее планировали схему без аппаратного рейда опираясь только на возможности ZFS.». Т.е. в данном случае интересует мотивация отказа от аппаратного рейда.
                                    0
                                    Мотивация простая. Есть ленточный бекапный сторадж, ему в помощь для оперативного бекапа нужно было некоторое количество места. стоимость сервера в данном конфиге составила 90 тысяч рублей. Достойный контроллер который бы сделал RAID5 из этих дисков с хорошим объёмом кеша обошёлся бы примерно в 1.5к$. что увеличило бы стоимость сервера в полтора раза. Опыт использования ZFS ранее сподвиг именно на эту конфигурацию. ZFS достаточно стабильна для использования в работе. по крайней мере у нас несколько серверов на ней крутятся. в том числе с нарезанными виндовыми правами на ресурсы. Ну и плюс ко всему это намного удобнее при динамической смене конфигурации системы.
                                      0
                                      Понятно. Значит первопричина экономическая.
                                      Сам сейчас стою перед выбором ФС под фряху. Брожу тут по сети и складывается впечатление, что с выходом восьмерки данная фс на этой оси очень становиться заманчива.

                                      Не на бэкап сервере, а где либо на продакшене данную фс уже использовать приходилось?
                                      За статью отдельное спасибо. Имхо на данный момент в рунете в контексте теоретического описания + практический опыт она самая лучшая.
                                        0
                                        За спасибо спасибо :)
                                        На продакшене стоит как хранилище всяческого хлама для PR отдела и как промежуточный сервер для обработки видеоматериалов.
                                    0
                                    Я совсем запутался. Можно или нельзя добавлять в пул ZFS новые диски и тем самым увеличивать емкость?
                                    Хотим в местной сетке сделать с помощью ZFS аля RAID5 (RAIDZ как я понял в терминологии ZFS).
                                    В разных источниках — кто что пишет, кто можно, кто нельзя.
                                      0
                                      только диски одинаковой емкости
                                        0
                                        Точнее, с объемом равным или большим самому маленькому диску в рейде.
                                          0
                                          И их туда можно только добавлять, а вот удалять — нельзя и это широко известный «ньюанс».
                                        0
                                        Из того что вычитал… нельзя в существующий raidz добавлять диски =(
                                        в документации по ZFS постоянно говорит о добавление устройств в пул mirror, про raidz ни слова
                                          0
                                          Скажите, почему нельзя было использовать статическую нумерацию дисков в ядре?
                                            0
                                            Просветите, зачем ставить vm.kmem_size меньше доступного объема ОЗУ?
                                              0
                                              Автору спасибо за проделанную работу и доходчивое объяснение.

                                              Уже есть zpool с данными, переносить их тупо некуда из-за объёма. Но хотелось бы избавится от вышеописанной ошибки, которая в прочем, есть и при работе zfs на Linux машинах. Можно ли как-то пофиксить на живом да так, чтобы ничего не попортить?
                                                0
                                                Я нашел более простой способ, как говорят KISS,- без записи меток на диск:

                                                zpool export mytank
                                                zpool import -d /dev/disk/by-id mytank
                                                

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое