Я только что вытащил SATA-кабель из 'sda' на новом тестовом сервере с ZFS RAID1, и не вижу никаких сообщений, хотя 'zpool status' показывает DEGRADED. Но сервер продолжает работать без перебоев, ура RAID/ZFS. РЕДАКТИРОВАНИЕ: После того как я снова подключил HDD и добавил его в пул ('zpool online rpool <dev>'), получил сообщение о завершении события resilver_finish. Но очевидно, что событие 'degraded' было бы критичным для получения!

Это абсолютно абсурдное поведение zed, и воспринимать это как "нормально" — плохая идея. Это нужно изменить. "Это всегда должно контролироваться из удаленного места..." Да, точно! Программное обеспечение находится в proxmox, и зачем же вкладывать средства во второй сервер, чтобы следить за жестким диском на первом сервере, когда все, что должен делать первый сервер, — это отправить нужное письмо, когда диск отключен. Вместо того чтобы делать это после того, как кто-то его снова подключит... Потому что, разумеется, если кто-то снова подключит его, он проверит статус zpool, пока не завершится восстановление, а письмо просто избыточно. Я только что сделал то же самое, выдернул кабель, ждал уведомления о неисправном диске... НИЧЕГО. Несколько секунд спустя после подключения обратно... Письмо о завершении восстановления диска появилось... 10 сентября 13:25:15 fs02 kernel: ata9: SATA link down (SStatus 0 SControl 300) 10 сентября 13:25:20 fs02 kernel: ata9: SATA link down (SStatus 0 SControl 300) 10 сентября 13:25:26 fs02 kernel: ata9: SATA link down (SStatus 0 SControl 300) 10 сентября 13:25:26 fs02 kernel: ata9.00: disabled 10 сентября 13:25:26 fs02 kernel: ata9.00: detaching (SCSI 8:0:0:0) 10 сентября 13:25:26 fs02 kernel: sd 8:0:0:0: [sdg] Синхронизация кэша SCSI 10 сентября 13:25:26 fs02 kernel: sd 8:0:0:0: [sdg] Синхронизация кэша(10) не удалась: Результат: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK 10 сентября 13:25:26 fs02 kernel: sd 8:0:0:0: [sdg] Остановка диска 10 сентября 13:25:26 fs02 kernel: sd 8:0:0:0: [sdg] Start/Stop Unit не удалась: Результат: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK 10 сентября 13:25:26 fs02 zed[29838]: eid=51 class=statechange pool_guid=0xD6BEA68E732464BF vdev_path=/dev/disk/by-id/ata-ST1000DM003-1CH162_S1D8PXZJ-part1 vdev_state=OFFLINE 10 сентября 13:25:27 fs02 zed[29970]: eid=52 class=config_sync pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:48 fs02 kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) 10 сентября 13:25:48 fs02 kernel: ata9.00: ATA-8: ST1000DM003-1CH162, CC46, max UDMA/133 10 сентября 13:25:48 fs02 kernel: ata9.00: 1953525168 секторов, multi 0: LBA48 NCQ (глубина 32), AA 10 сентября 13:25:48 fs02 kernel: ata9.00: настроен для UDMA/133 10 сентября 13:25:48 fs02 kernel: scsi 8:0:0:0: Прямой доступ ATA ST1000DM003-1CH1 CC46 PQ: 0 ANSI: 5 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: Присоединен scsi generic sg6 тип 0 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] 1953525168 512-байтных логических блоков: (1.00 TB/932 GiB) 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] 4096-байтные физические блоки 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] Защита от записи отключена 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] Режим Sensе: 00 3a 00 00 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] Кэш записи: включен, кэш чтения: включен, не поддерживает DPO или FUA 10 сентября 13:25:48 fs02 kernel: sdg: sdg1 sdg9 10 сентября 13:25:48 fs02 kernel: sd 8:0:0:0: [sdg] Присоединен диск SCSI 10 сентября 13:25:49 fs02 zed[30529]: eid=53 class=statechange pool_guid=0xD6BEA68E732464BF vdev_path=/dev/disk/by-id/ata-ST1000DM003-1CH162_S1D8PXZJ-part1 vdev_state=ONLINE 10 сентября 13:25:49 fs02 zed[30642]: eid=54 class=vdev_online pool_guid=0xD6BEA68E732464BF vdev_path=/dev/disk/by-id/ata-ST1000DM003-1CH162_S1D8PXZJ-part1 vdev_state=ONLINE 10 сентября 13:25:50 fs02 zed[30794]: eid=55 class=resilver_start pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:50 fs02 zed[30815]: eid=56 class=history_event pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:51 fs02 zed[31079]: eid=57 class=history_event pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:51 fs02 zed[31094]: eid=58 class=resilver_finish pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:51 fs02 postfix/pickup[20422]: BD2F566123: uid=0 от=<root> 10 сентября 13:25:51 fs02 postfix/cleanup[29598]: BD2F566123: message-id=<20200910112551.BD2F566123@fs02.winwinsol.local> 10 сентября 13:25:51 fs02 postfix/qmgr[20423]: BD2F566123: от=<root@fs02.winwinsol.local>, size=1673, nrcpt=1 (очередь активна) 10 сентября 13:25:51 fs02 zed[31109]: eid=59 class=config_sync pool_guid=0xD6BEA68E732464BF 10 сентября 13:25:51 fs02 postfix/smtp[29601]: подключение к smtp.gmail.com[2a00:1450:4013:c03::6d]:587: Сеть недоступна 10 сентября 13:25:53 fs02 postfix/smtp[29601]: BD2F566123: к=<XXXXXX@gmail.com>, реле=smtp.gmail.com[74.125.143.109]:587, задержка=1.5, задержки=0/0/0.61/0.9, dsn=2.0.0, статус=отправлено (250 2.0.0 OK 1599737153 la17sm6701717ejb.62 - gsmtp) 10 сентября 13:25:53 fs02 postfix/qmgr[20423]: BD2F566123: удалено

Я недавно получил сообщение о том, что "диск вышел из строя" от ZED. Выглядело это так: количество ошибок ввода-вывода, связанных с устройством ZFS, превысило допустимые уровни. ZFS пометил устройство как неисправное. Влияние: устойчивость пула может быть нарушена. eid: 190 class: statechange state: FAULTED host: file time: 2020-12-11 19:54:45+0100 vpath: /dev/disk/by-vdev/C0-S4-part1 vphys: pci-0000:01:00.0-sas-phy0-lun-0 vguid: 0xD924681D17354751 devid: scsi-35000039a48d30040-part1 pool: 0x8DF3E60A74E576F0 Так что я, пожалуй, не буду винить ZED в этом... Но должен признать, что это был другой тип сбоя (порт данных не был отключен).