Incidents étranges sur disques SSD sur H730
Hello all, Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC) L’incident donne ceci au niveau dmesg : [630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 Ça dure donc quelques secondes max. Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était. Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1). Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid. Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ? Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment. Merci David Ponzone
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral. Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système. Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano. On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Donc le mode HBA de la 730 est l’équivalent de flasher une 330 ? David Ponzone
Le 19 mars 2022 à 16:07, Jarod G. <skid+frsag@tuto-craft.com> a écrit :
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système.
Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano.
On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
HBA330 oui, pas H330. Le sam. 19 mars 2022 à 16:02, David Ponzone <david.ponzone@gmail.com> a écrit :
Donc le mode HBA de la 730 est l’équivalent de flasher une 330 ?
David Ponzone
Le 19 mars 2022 à 16:07, Jarod G. <skid+frsag@tuto-craft.com> a écrit :
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système.
Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano. On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)shttp://www.frsag.org/
Pareil en mode HBA. Pour reproduire le problème, j’ai fait ça: -10 dd simultanés de urandom vers pool zfs, 256Go chacun, ça a pris un moment, et un scrub en même temps -> aucun problème -dd de 5 des fichiers créés précédemment vers le pool zfs (donc READ et WRITE en même temps sur les SSD) -> ça tourne normalement pendant 8 min -je lance un scrub en même temps, ça roule pendant 3/4 min et là, PAF, succession d’erreurs READ/WRITE et mon pool se retrouve dans cet état: pool: zfsPool state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: resilvered 1.99M in 00:00:04 with 0 errors on Mon Mar 21 19:55:26 2022 config: NAME STATE READ WRITE CKSUM zfsPool DEGRADED 0 0 0 raidz2-0 DEGRADED 3 10 0 scsi-35000cca050ae9fe8 DEGRADED 4 11 2 too many errors scsi-35000cca050ae9c4c DEGRADED 4 14 2 too many errors scsi-35000cca050ae6e18 FAULTED 3 14 2 too many errors scsi-35000cca050ac2d48 DEGRADED 4 8 0 too many errors scsi-35000cca050ae4d68 ONLINE 4 5 2 scsi-35000cca050ae9280 FAULTED 4 10 0 too many errors errors: No known data errors Mais ça augmente plus ensuite (il semble y avoir eu 2 interruptions sur le bus de suite, c’est tout), les 5 dd se terminent ensuite 3/4 min après, sans nouvelles erreurs. Sérieusement incompréhensible. Ca semble quand même arriver quand il y a des accès violents READ et WRITE sur le bus, je vais essayer de reproduire.
Le 19 mars 2022 à 15:07, Jarod G. <skid+frsag@tuto-craft.com> a écrit :
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système.
Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano.
On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com <mailto:david.ponzone@gmail.com>> a écrit : Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Hello, As-tu regardé si tu avais plus d'infos/status dans les logs de l'IDRAC ? Je ne sais pas si le mode HBA utilise la "battery cache" mais ça peut être une piste Fabien Le 21/03/2022 à 20:13, David Ponzone a écrit :
Pareil en mode HBA.
Pour reproduire le problème, j’ai fait ça: -10 dd simultanés de urandom vers pool zfs, 256Go chacun, ça a pris un moment, et un scrub en même temps -> aucun problème -dd de 5 des fichiers créés précédemment vers le pool zfs (donc READ et WRITE en même temps sur les SSD) -> ça tourne normalement pendant 8 min -je lance un scrub en même temps, ça roule pendant 3/4 min et là, PAF, succession d’erreurs READ/WRITE et mon pool se retrouve dans cet état:
pool: zfsPool state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: resilvered 1.99M in 00:00:04 with 0 errors on Mon Mar 21 19:55:26 2022 config:
NAME STATE READ WRITE CKSUM zfsPool DEGRADED 0 0 0 raidz2-0 DEGRADED 3 10 0 scsi-35000cca050ae9fe8 DEGRADED 4 11 2 too many errors scsi-35000cca050ae9c4c DEGRADED 4 14 2 too many errors scsi-35000cca050ae6e18 FAULTED 3 14 2 too many errors scsi-35000cca050ac2d48 DEGRADED 4 8 0 too many errors scsi-35000cca050ae4d68 ONLINE 4 5 2 scsi-35000cca050ae9280 FAULTED 4 10 0 too many errors
errors: No known data errors
Mais ça augmente plus ensuite (il semble y avoir eu 2 interruptions sur le bus de suite, c’est tout), les 5 dd se terminent ensuite 3/4 min après, sans nouvelles erreurs.
Sérieusement incompréhensible. Ca semble quand même arriver quand il y a des accès violents READ et WRITE sur le bus, je vais essayer de reproduire.
Le 19 mars 2022 à 15:07, Jarod G. <skid+frsag@tuto-craft.com> a écrit :
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système.
Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano.
On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour, Mes questions à deux balles : -Firmware à jour (y compris les SSD) ? -Etat SMART des SSD ? -version du driver fournit par debian/proxmox (voir du "firmware", du paquet "linux-firmware-nonfree" je crois)? -Pour rappel, proxmox a son propre noyau, un soucis à ce niveau ??? Cdlt, Le mar. 22 mars 2022 à 08:09, Fabien <list@fgautreau.net> a écrit :
Hello,
As-tu regardé si tu avais plus d'infos/status dans les logs de l'IDRAC ?
Je ne sais pas si le mode HBA utilise la "battery cache" mais ça peut être une piste
Fabien
Le 21/03/2022 à 20:13, David Ponzone a écrit :
Pareil en mode HBA.
Pour reproduire le problème, j’ai fait ça: -10 dd simultanés de urandom vers pool zfs, 256Go chacun, ça a pris un moment, et un scrub en même temps -> aucun problème -dd de 5 des fichiers créés précédemment vers le pool zfs (donc READ et WRITE en même temps sur les SSD) -> ça tourne normalement pendant 8 min -je lance un scrub en même temps, ça roule pendant 3/4 min et là, PAF, succession d’erreurs READ/WRITE et mon pool se retrouve dans cet état:
pool: zfsPool state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: resilvered 1.99M in 00:00:04 with 0 errors on Mon Mar 21 19:55:26 2022 config:
NAME STATE READ WRITE CKSUM zfsPool DEGRADED 0 0 0 raidz2-0 DEGRADED 3 10 0 scsi-35000cca050ae9fe8 DEGRADED 4 11 2 too many errors scsi-35000cca050ae9c4c DEGRADED 4 14 2 too many errors scsi-35000cca050ae6e18 FAULTED 3 14 2 too many errors scsi-35000cca050ac2d48 DEGRADED 4 8 0 too many errors scsi-35000cca050ae4d68 ONLINE 4 5 2 scsi-35000cca050ae9280 FAULTED 4 10 0 too many errors
errors: No known data errors
Mais ça augmente plus ensuite (il semble y avoir eu 2 interruptions sur le bus de suite, c’est tout), les 5 dd se terminent ensuite 3/4 min après, sans nouvelles erreurs.
Sérieusement incompréhensible. Ca semble quand même arriver quand il y a des accès violents READ et WRITE sur le bus, je vais essayer de reproduire.
Le 19 mars 2022 à 15:07, Jarod G. <skid+frsag@tuto-craft.com> a écrit :
C'est ce que j'allais envoyer, en mode non-raid la carte gère toujours le traitement de quelques trucs et cache certaines infos des disques au système.
Heureusement depuis les cartes séries 30 on peut directement passer en mode HBA sans devoir flasher le firmware à la mano. On 19/03/2022 12:12, Maxime De Berraly wrote:
Le mode "nonraid" par disque est pourri. Passe la H730 en mode HBA intégral.
Le sam. 19 mars 2022 à 11:47, David Ponzone <david.ponzone@gmail.com> a écrit :
Hello all,
Sur 2 serveurs r630 que je suis en train de mettre en service (progressivement), j’ai eu le même incident, à chaque fois quelques jours après avoir mis en prod une 20aine de VM. Les 2 serveurs sont identiques: -R630 avec H730 entièrement à jour -Proxmox 7.1 installé sur 2 HD SAS en raid 1 -pool ZFS raidz2 sur 6 SSD IBM 1.6To SAS 12Gbps (déclarés en non-Raid sur la PERC)
L’incident donne ceci au niveau dmesg :
[630190.562386] sd 0:0:3:0: [sdb] tag#437 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630190.562392] sd 0:0:3:0: [sdb] tag#437 Sense Key : Data Protect [current] [630190.562395] sd 0:0:3:0: [sdb] tag#437 Add. Sense: Access denied - no access rights[630190.562397] sd 0:0:3:0: [sdb] tag#437 CDB: Write(10) 2a 00 b4 8a 19 e8 00 01 00 00[630190.562399] blk_update_request: critical target error, dev sdb, sector 3028949480 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0 [630190.562448] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=2 offset=1550821085184 size=131072 flags=40080c80 [630201.009893] sd 0:0:7:0: [sdf] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.009899] sd 0:0:7:0: [sdf] tag#405 Sense Key : Data Protect [current] [630201.009901] sd 0:0:7:0: [sdf] tag#405 Add. Sense: Access denied - no access rights[630201.009903] sd 0:0:7:0: [sdf] tag#405 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.009905] blk_update_request: critical target error, dev sdf, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.009955] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae63cc-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8 [630201.010013] sd 0:0:2:0: [sda] tag#408 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010016] sd 0:0:2:0: [sda] tag#408 Sense Key : Data Protect [current] [630201.010018] sd 0:0:2:0: [sda] tag#408 Add. Sense: Access denied - no access rights[630201.010020] sd 0:0:2:0: [sda] tag#408 CDB: Read(10) 28 00 b4 8a 19 90 00 00 a8 00 [630201.010021] blk_update_request: critical target error, dev sda, sector 3028949392 op 0x0:(READ) flags 0x700 phys_seg 21 prio class 0 [630201.010116] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae4dcc-part1 error=121 type=1 offset=1550821040128 size=86016 flags=40080ca8 [630201.010525] sd 0:0:6:0: [sde] tag#403 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.010547] sd 0:0:6:0: [sde] tag#403 Sense Key : Data Protect [current] [630201.010553] sd 0:0:6:0: [sde] tag#403 Add. Sense: Access denied - no access rights[630201.010560] sd 0:0:6:0: [sde] tag#403 CDB: Read(10) 28 00 b4 8a 19 a8 00 00 70 00 [630201.010565] blk_update_request: critical target error, dev sde, sector 3028949416 op 0x0:(READ) flags 0x700 phys_seg 12 prio class 0 [630201.010713] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae6e78-part1 error=121 type=1 offset=1550821052416 size=57344 flags=40080ca8 [630201.045323] sd 0:0:3:0: [sdb] tag#433 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [630201.045328] sd 0:0:3:0: [sdb] tag#433 Sense Key : Data Protect [current] [630201.045330] sd 0:0:3:0: [sdb] tag#433 Add. Sense: Access denied - no access rights[630201.045332] sd 0:0:3:0: [sdb] tag#433 CDB: Read(10) 28 00 b4 8a 19 b0 00 00 70 00 [630201.045333] blk_update_request: critical target error, dev sdb, sector 3028949424 op 0x0:(READ) flags 0x700 phys_seg 14 prio class 0 [630201.045383] zio pool=zfsPool vdev=/dev/disk/by-id/scsi-35000cca050ae89a0-part1 error=121 type=1 offset=1550821056512 size=57344 flags=40080ca8
Ça dure donc quelques secondes max.
Évidemment après ça, le pool est en sale état: 2 SSD en faulted, 2 en degraded, mais pas d’impact sur les données, et si je fais un clear, ça resilver et ça repart comme si de rien n’était.
Dans les logs PERC: rien (peut être normal en non-raid mais alors ça veut dire qu’il n’y a pas eu de problèmes sur les 2 HD en raid1).
Ça fait penser à un problème que le driver megaraid aurait eu ponctuellement pour accéder physiquement aux SSD en non-raid.
Comme c’est arrivé sur les deux serveurs, le problème hardware semble impossible. Par contre, incompatibilité de ZFS et/ou H730 et/ou megaraid et/ou SSD IBM ?
Je nage un peu pour le moment donc avant de me lancer dans des grandes opérations chronophages (swap des SSD pour un autre modèle SATA, remplacement de la H730 par une 330 flashée en IT,…), je préfère voir si ca dit quelque chose à quelqu’un. Google s’est avéré useless pour le moment.
Merci
David Ponzone
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)shttp://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)shttp://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 22 mars 2022 à 09:13, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Mes questions à deux balles : -Firmware à jour (y compris les SSD) ?
Yep
-Etat SMART des SSD ?
RAS sur aucun des 6
-version du driver fournit par debian/proxmox (voir du "firmware", du paquet "linux-firmware-nonfree" je crois)?
filename: /lib/modules/5.13.19-4-pve/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: Broadcom MegaRAID SAS Driver author: megaraidlinux.pdl@broadcom.com version: 07.714.04.00-rc1
-Pour rappel, proxmox a son propre noyau, un soucis à ce niveau ???
Tout est possible mais difficile à vérifier. J’ai lancé des tests en charge après avoir passé les PD en 6G et rebooté. Wait&see Merci pour les retours en tout cas, je pense que je suis tombé sur un glitch.
Et avec d'autres SSD ? Et avec une autre saveur de GNU/Linux (Fedora, Debian (pour le noyau)) ? Le 22/03/2022, David Ponzone<david.ponzone@gmail.com> a écrit :
Le 22 mars 2022 à 09:13, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Mes questions à deux balles : -Firmware à jour (y compris les SSD) ?
Yep
-Etat SMART des SSD ?
RAS sur aucun des 6
-version du driver fournit par debian/proxmox (voir du "firmware", du paquet "linux-firmware-nonfree" je crois)?
filename: /lib/modules/5.13.19-4-pve/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: Broadcom MegaRAID SAS Driver author: megaraidlinux.pdl@broadcom.com version: 07.714.04.00-rc1
-Pour rappel, proxmox a son propre noyau, un soucis à ce niveau ???
Tout est possible mais difficile à vérifier.
J’ai lancé des tests en charge après avoir passé les PD en 6G et rebooté. Wait&see
Merci pour les retours en tout cas, je pense que je suis tombé sur un glitch.
Le 22 mars 2022 à 14:01, Matic Vari <varimatic@gmail.com> a écrit :
Et avec d'autres SSD ?
Au passage, pour le moment, j’ai pas réussi à reproduire le problème depuis que j’ai forcé les SSD en 6Gbps. Je vais bientôt tester avec des SSD Intel 6Gbps.
Et avec une autre saveur de GNU/Linux (Fedora, Debian (pour le noyau)) ?
Pas trop le temps et l’envie de tester ça. Proxmox est livré prêt-à-installer sur Debian, je vais pas remettre leur choix en question. Ca serait générer d’autres problèmes potentiellement.
Première conclusion: j’ai quand même beaucoup plus de mal à provoquer l’incident avec les SSD forcés en 6G. J’ai réussi qu’une fois hier, malgré des DD et des scrubs simultanés à répétition. En 12G, il ne faut pas un heure pour que le problème survienne. EDIT: je retire ce que je viens d’écrire, je viens de relancer 5 DD et un scrub et ça recommence, en 6Gbps. EDIT2: Je fais donc un clear, je relance la même opération, et là, rien. Il y a donc un glitch, et une bonne part de hasard, ce qui est pas non plus anormal avec un glitch. Mais hasard qui semble quand même statistiquement moins fréquent en baissant la vitesse de bus négociée par les SSD. Ce qui est étonnant, c’est que je ne trouve toujours pas la moindre trace de quelqu’un ayant eu un problème similaire.
J’ai lancé des tests en charge après avoir passé les PD en 6G et rebooté. Wait&see
Bonjour, En regardant la datasheet de la carte perc je suis tombé la dessus: Connectors -> Two internal HD Mini-SAS SFF8643 Data transfer rates -> Up to 12Gbps per port Comment as-tu configuré les ports de ta carte RAID ? N'atteindrais-tu pas les limites de ta carte RAID lors de tes différent tests ? (par exemple si tes SSD sont sur le même port de ta carte) Peux-etre faut il étaler les disques sur les deux ports ? Cela n'a peut être rien à voir mais ne sait on jamais :) Un bout de doc sur le sujet: https://docs.broadcom.com/doc/12353459 Fabien Le 2022-03-23 08:30, David Ponzone a écrit :
Première conclusion: j’ai quand même beaucoup plus de mal à provoquer l’incident avec les SSD forcés en 6G. J’ai réussi qu’une fois hier, malgré des DD et des scrubs simultanés à répétition. En 12G, il ne faut pas un heure pour que le problème survienne.
EDIT: je retire ce que je viens d’écrire, je viens de relancer 5 DD et un scrub et ça recommence, en 6Gbps.
EDIT2: Je fais donc un clear, je relance la même opération, et là, rien.
Il y a donc un glitch, et une bonne part de hasard, ce qui est pas non plus anormal avec un glitch. Mais hasard qui semble quand même statistiquement moins fréquent en baissant la vitesse de bus négociée par les SSD.
Ce qui est étonnant, c’est que je ne trouve toujours pas la moindre trace de quelqu’un ayant eu un problème similaire.
J’ai lancé des tests en charge après avoir passé les PD en 6G et rebooté. Wait&see
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 23 mars 2022 à 13:26, Fabien <list@fgautreau.net> a écrit :
Bonjour,
En regardant la datasheet de la carte perc je suis tombé la dessus: Connectors -> Two internal HD Mini-SAS SFF8643 Data transfer rates -> Up to 12Gbps per port
Comment as-tu configuré les ports de ta carte RAID ?
N'atteindrais-tu pas les limites de ta carte RAID lors de tes différent tests ? (par exemple si tes SSD sont sur le même port de ta carte)
Peux-etre faut il étaler les disques sur les deux ports ?
Cela n'a peut être rien à voir mais ne sait on jamais :)
Un bout de doc sur le sujet: https://docs.broadcom.com/doc/12353459
Hmm j’ai pas l’habitude de changer quoi que ce soit quand je reçois un Dell R630 :) Les SDD sont dans les slots 2 à 7 hotplug en facade. Et même si on tapait au limite de la carte, depuis quand on a des erreurs quand on tape au limite d’un bus ? Y a pas grand chose qui marcherait en informatique si c’était le cas :) Voir mon mail d’il y a quelques minutes, j’ai avancé depuis sur la cause possible.
Bonjour David, Le 23/03/2022 à 08:30, David Ponzone a écrit :
Première conclusion: j’ai quand même beaucoup plus de mal à provoquer l’incident avec les SSD forcés en 6G. J’ai réussi qu’une fois hier, malgré des DD et des scrubs simultanés à répétition. En 12G, il ne faut pas un heure pour que le problème survienne.
EDIT: je retire ce que je viens d’écrire, je viens de relancer 5 DD et un scrub et ça recommence, en 6Gbps.
EDIT2: Je fais donc un clear, je relance la même opération, et là, rien.
Il y a donc un glitch, et une bonne part de hasard, ce qui est pas non plus anormal avec un glitch. Mais hasard qui semble quand même statistiquement moins fréquent en baissant la vitesse de bus négociée par les SSD.
Ce qui est étonnant, c’est que je ne trouve toujours pas la moindre trace de quelqu’un ayant eu un problème similaire.
Tu n'es pas le seul :-) Mais usuellement, je vois plutôt ce problème de contention avec des disques Dell rotatifs "Nearline" SAS comme les 16 To par exemple. As-tu essayé avec des disques SAS SSD Dell pour comparer ? As-tu trouvé un moyen de connaitre la véritable charge I/O des slots ou des ports ? Bon courage. -- *Emmanuel DECAEN*
Le 23 mars 2022 à 13:27, Emmanuel DECAEN <Emmanuel.Decaen@xsalto.com> a écrit :
Bonjour David,
Le 23/03/2022 à 08:30, David Ponzone a écrit :
Première conclusion: j’ai quand même beaucoup plus de mal à provoquer l’incident avec les SSD forcés en 6G. J’ai réussi qu’une fois hier, malgré des DD et des scrubs simultanés à répétition. En 12G, il ne faut pas un heure pour que le problème survienne.
EDIT: je retire ce que je viens d’écrire, je viens de relancer 5 DD et un scrub et ça recommence, en 6Gbps.
EDIT2: Je fais donc un clear, je relance la même opération, et là, rien.
Il y a donc un glitch, et une bonne part de hasard, ce qui est pas non plus anormal avec un glitch. Mais hasard qui semble quand même statistiquement moins fréquent en baissant la vitesse de bus négociée par les SSD.
Ce qui est étonnant, c’est que je ne trouve toujours pas la moindre trace de quelqu’un ayant eu un problème similaire.
Tu n'es pas le seul :-) Mais usuellement, je vois plutôt ce problème de contention avec des disques Dell rotatifs "Nearline" SAS comme les 16 To par exemple.
As-tu essayé avec des disques SAS SSD Dell pour comparer ?
Je vais passer sur des Intel bientôt, de même capa.
As-tu trouvé un moyen de connaitre la véritable charge I/O des slots ou des ports ?
Je sais pas si tu as vu mon mail de toute à l’heure, mais ça sent plutôt: -le bug-dinguerie qui fait croire au driver megaraid que certains secteurs sont inaccessibles -problème de firmware IBM (IBM n’a pas très bonne réputation avec son firmware sur les SSD HGST, d’après ce que j’ai lu) -les 2
Bonjour, Le 23/03/2022 à 18:14, David Ponzone a écrit :
Le 23 mars 2022 à 13:27, Emmanuel DECAEN <Emmanuel.Decaen@xsalto.com> a écrit :
Bonjour David,
Le 23/03/2022 à 08:30, David Ponzone a écrit :
Il y a donc un glitch, et une bonne part de hasard, ce qui est pas non plus anormal avec un glitch. Mais hasard qui semble quand même statistiquement moins fréquent en baissant la vitesse de bus négociée par les SSD.
Ce qui est étonnant, c’est que je ne trouve toujours pas la moindre trace de quelqu’un ayant eu un problème similaire.
Tu n'es pas le seul :-) Mais usuellement, je vois plutôt ce problème de contention avec des disques Dell rotatifs "Nearline" SAS comme les 16 To par exemple.
As-tu essayé avec des disques SAS SSD Dell pour comparer ?
Je vais passer sur des Intel bientôt, de même capa.
As-tu trouvé un moyen de connaitre la véritable charge I/O des slots ou des ports ?
Je sais pas si tu as vu mon mail de toute à l’heure, mais ça sent plutôt: -le bug-dinguerie qui fait croire au driver megaraid que certains secteurs sont inaccessibles
Je pense que tu atteins le limite du produit, les SSD haut de gamme serveurs sont mieux dimensionnés que les SSD classiques. En particulier sur l'interface, la latence et l'over provisioning: https://www.kingston.com/fr/blog/pc-performance/enterprise-versus-client-ssd Et même au sein des SSD serveurs, il y a des différences :-)
-problème de firmware IBM (IBM n’a pas très bonne réputation avec son firmware sur les SSD HGST, d’après ce que j’ai lu) -les 2
Quand je vois la différence de taille et de poids entre deux types de SSD "serveur" de même capacité, je me dis que ce n'est pas tout à fait le même produit ;-) Si tu as moyen de te faire prêter des SSD SAS Dell 12G performant et récent, tu pourras tester et potentiellement isoler le problème. Bon courage. -- *Emmanuel DECAEN* E-Mail: ed@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07
J’avance. Je me permets de vous tenir au courant parce que en dehors des idées que vous pourriez avoir, ça peut un jour aider quelqu’un. J’ai fini par comprendre que le problème se produit toujours sur des secteurs de la fin des SSD (vers 1.55To sur un SSD 1.6To). Je n’ai pas encore pu le voir sur des secteurs du début ou du milieu. C’est d’ailleurs comme ça que je le provoque: en faisant des DD qui remplissent le pool, ZFS finit par devoir taper dans ces secteurs là. Alors, on va me dire: tes SSD ont des secteurs défectueux. Le problème c’est que je vois souvent le même secteur sortir sur plusieurs SSD. Et les secteurs sont toujours dans la même zone (248 secteurs entre le premier et le dernier). Et si je compare entre les 2 serveurs, ils sont toujours dans le même coin, voir identiques: SERVEUR 1: 3028949248 3028949256 3028949264 3028949320 3028949328 3028949336 3028949344 3028949368 3028949376 3028949384 3028949392 3028949400 3028949424 3028949432 3028949440 3028949448 3028949456 3028949464 3028949472 3028949480 3028949488 3028949496 SERVEUR 2 (j’ai beaucoup moins joué avec, il y a des VM en prod dessus): 3028949392 3028949416 3028949424 3028949480 Donc je ne crois pas à un hasard, c’est statistiquement inimaginable. Si quelqu’un sait pourquoi il y aurait des secteurs interdits sur un SSD IBM (OEM HGST), alors qu’ils ne sont pas en fin de disque dans une zone réservée, mais vers la fin de la partition 1 de ZFS (donc la partition data), je suis preneur.
Le Wed, Mar 23, 2022 at 01:26:43PM +0100, David Ponzone [david.ponzone@gmail.com] a écrit:
J???avance.
Je me permets de vous tenir au courant parce que en dehors des idées que vous pourriez avoir, ça peut un jour aider quelqu???un.
J???ai fini par comprendre que le problème se produit toujours sur des secteurs de la fin des SSD (vers 1.55To sur un SSD 1.6To).
Peut-etre que tes SSD ne font pas réellement 1.6To "réels" mais que c'est une capacité "brute" pour de la réallocation, et que le firmware est buggé et ne le gere pas correctement ( en annoncant une taille plus petite, du coup ) ? </speciulations> -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
J’y ai pensé, mais si c’était le cas, ça commencerait à merder après le secteur X (X dans mon cas étant autour de 3028949248). Mais j’ai pu faire des lectures sans erreurs sur des secteurs après cette zone là. Et pour répondre à Emmanuel hier, les IBM-SSG c’est du HGST Enterprise prévu pour 8 ou 10 écritures complètes par jour pendant des années, je sais pas où il est allé chercher que c’était du SSD GP :)
Le 25 mars 2022 à 13:26, Dominique Rousseau <d.rousseau@nnx.com> a écrit :
Le Wed, Mar 23, 2022 at 01:26:43PM +0100, David Ponzone [david.ponzone@gmail.com] a écrit:
J???avance.
Je me permets de vous tenir au courant parce que en dehors des idées que vous pourriez avoir, ça peut un jour aider quelqu???un.
J???ai fini par comprendre que le problème se produit toujours sur des secteurs de la fin des SSD (vers 1.55To sur un SSD 1.6To).
Peut-etre que tes SSD ne font pas réellement 1.6To "réels" mais que c'est une capacité "brute" pour de la réallocation, et que le firmware est buggé et ne le gere pas correctement ( en annoncant une taille plus petite, du coup ) ? </speciulations>
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Je complète, car je viens de découvrir que c’est beaucoup plus tordu que ça! Je fais un dd read de 256 secteurs à partir de 3028949200: dmesg m’envoie un erreur de read sur le secteur 3028949432. Je refais un dd read de 2560 secteurs à partir de 3028949200: PAS d’ERREUR ! Je refais un dd read de 256 secteurs à partir de 3028949200: PAS d’ERREUR !!!! Donc en gros, si je fais un gros read, ça élimine le problème (provisoirement ou pas, aucune idée, je vais ré-essayer un read de 256 dans quelques heures) Y a un truc pourri dans mon royaume…. David
Le 25 mars 2022 à 13:36, David Ponzone <david.ponzone@gmail.com> a écrit :
J’y ai pensé, mais si c’était le cas, ça commencerait à merder après le secteur X (X dans mon cas étant autour de 3028949248). Mais j’ai pu faire des lectures sans erreurs sur des secteurs après cette zone là.
Et pour répondre à Emmanuel hier, les IBM-SSG c’est du HGST Enterprise prévu pour 8 ou 10 écritures complètes par jour pendant des années, je sais pas où il est allé chercher que c’était du SSD GP :)
Le 25 mars 2022 à 13:26, Dominique Rousseau <d.rousseau@nnx.com> a écrit :
Le Wed, Mar 23, 2022 at 01:26:43PM +0100, David Ponzone [david.ponzone@gmail.com] a écrit:
J???avance.
Je me permets de vous tenir au courant parce que en dehors des idées que vous pourriez avoir, ça peut un jour aider quelqu???un.
J???ai fini par comprendre que le problème se produit toujours sur des secteurs de la fin des SSD (vers 1.55To sur un SSD 1.6To).
Peut-etre que tes SSD ne font pas réellement 1.6To "réels" mais que c'est une capacité "brute" pour de la réallocation, et que le firmware est buggé et ne le gere pas correctement ( en annoncant une taille plus petite, du coup ) ? </speciulations>
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Et je complète encore avec mes derniers résultats: J’ai sorti un des SSD du pool ZFS, je l’ai remis en mode RAID au lieu de HBA, j’ai créé un VD RAID0 avec ce SSD. Quand je fais des tests de lecture sur le VD dans la zone des secteurs qui posent problème: aucune erreur pour le moment. Donc ça ressemble à un firmware IBM avec une saloperie que le contrôleur RAID de DELL sait gérer, mais pas le driver megaraid….
Le 25 mars 2022 à 13:55, David Ponzone <david.ponzone@gmail.com> a écrit :
Je complète, car je viens de découvrir que c’est beaucoup plus tordu que ça!
Je fais un dd read de 256 secteurs à partir de 3028949200: dmesg m’envoie un erreur de read sur le secteur 3028949432. Je refais un dd read de 2560 secteurs à partir de 3028949200: PAS d’ERREUR ! Je refais un dd read de 256 secteurs à partir de 3028949200: PAS d’ERREUR !!!!
Donc en gros, si je fais un gros read, ça élimine le problème (provisoirement ou pas, aucune idée, je vais ré-essayer un read de 256 dans quelques heures)
Y a un truc pourri dans mon royaume….
David
Le 25 mars 2022 à 13:36, David Ponzone <david.ponzone@gmail.com <mailto:david.ponzone@gmail.com>> a écrit :
J’y ai pensé, mais si c’était le cas, ça commencerait à merder après le secteur X (X dans mon cas étant autour de 3028949248). Mais j’ai pu faire des lectures sans erreurs sur des secteurs après cette zone là.
Et pour répondre à Emmanuel hier, les IBM-SSG c’est du HGST Enterprise prévu pour 8 ou 10 écritures complètes par jour pendant des années, je sais pas où il est allé chercher que c’était du SSD GP :)
Le 25 mars 2022 à 13:26, Dominique Rousseau <d.rousseau@nnx.com <mailto:d.rousseau@nnx.com>> a écrit :
Le Wed, Mar 23, 2022 at 01:26:43PM +0100, David Ponzone [david.ponzone@gmail.com <mailto:david.ponzone@gmail.com>] a écrit:
J???avance.
Je me permets de vous tenir au courant parce que en dehors des idées que vous pourriez avoir, ça peut un jour aider quelqu???un.
J???ai fini par comprendre que le problème se produit toujours sur des secteurs de la fin des SSD (vers 1.55To sur un SSD 1.6To).
Peut-etre que tes SSD ne font pas réellement 1.6To "réels" mais que c'est une capacité "brute" pour de la réallocation, et que le firmware est buggé et ne le gere pas correctement ( en annoncant une taille plus petite, du coup ) ? </speciulations>
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop <http://www.neuronnexion.coop/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Avec ou sans le ADRA (ADaptative Read Ahead) / RA activé en mode RAID ? Ca n'existe pas en mode HBA, comme le NV cache. Le firmware du SSD est a jour ? Il n'y a pas moyen de le cross-flasher avec le FW du constructeur d'origine ? On vendredi 25 mars 2022 16:57:06 CET, David Ponzone wrote:
Et je complète encore avec mes derniers résultats:
J’ai sorti un des SSD du pool ZFS, je l’ai remis en mode RAID au lieu de HBA, j’ai créé un VD RAID0 avec ce SSD. Quand je fais des tests de lecture sur le VD dans la zone des secteurs qui posent problème: aucune erreur pour le moment.
Donc ça ressemble à un firmware IBM avec une saloperie que le contrôleur RAID de DELL sait gérer, mais pas le driver megaraid….
Le 25 mars 2022 à 13:55, David Ponzone <david.ponzone@gmail.com> a écrit :
Je complète, car je viens de découvrir que c’est beaucoup plus tordu que ça!
Je fais un dd read de 256 secteurs à partir de 3028949200: dmesg m’envoie un erreur de read sur le secteur 3028949432. Je refais un dd read de 2560 secteurs à partir de 3028949200: PAS d’ERREUR ! Je refais un dd read de 256 secteurs à partir de 3028949200: PAS d’ERREUR !!!! ...
Le 25 mars 2022 à 17:13, Vincent Tondellier <tonton+frsag@team1664.org> a écrit :
Avec ou sans le ADRA (ADaptative Read Ahead) / RA activé en mode RAID ?
0/0 RAID0 Optl RW Yes RWBD - OFF 1.454 TB Donc oui, RA activé.
Ca n'existe pas en mode HBA, comme le NV cache.
Le firmware du SSD est a jour ?
A priori. En tout cas, mon fournisseur a des piles du même SSD, même firmware, en RAID sur DELL PERC ou HP MSA, sans aucun souci.
Il n'y a pas moyen de le cross-flasher avec le FW du constructeur d'origine ?
J’ai cherché et j’ai pas trouvé. Raison pour lequel on part sur remplacement par de l’Intel.
On vendredi 25 mars 2022 17:31:53 CET, David Ponzone wrote:
Le 25 mars 2022 à 17:13, Vincent Tondellier a écrit : Avec ou sans le ADRA (ADaptative Read Ahead) / RA activé en mode RAID ?
0/0 RAID0 Optl RW Yes RWBD - OFF 1.454 TB
Donc oui, RA activé.
Du coup ca masque potentiellement les bugs avec les lectures de quelques secteurs ...
Raison pour lequel on part sur remplacement par de l’Intel.
Les micron 5300/7300 PRO/MAX ont aussi bonne réputation (pas testé, j'ai pas encore réussi a tuer les intel que j'ai), du moins pour ceph et postgresql. Ca peut etre une alternative, Intel est en train de sortir du marché des SSD (sauf pour Optane) et a revendu la techno a SK Hynix
Le 25 mars 2022 à 17:57, Vincent Tondellier <tonton+frsag@team1664.org> a écrit :
On vendredi 25 mars 2022 17:31:53 CET, David Ponzone wrote:
Le 25 mars 2022 à 17:13, Vincent Tondellier a écrit : Avec ou sans le ADRA (ADaptative Read Ahead) / RA activé en mode RAID ?
0/0 RAID0 Optl RW Yes RWBD - OFF 1.454 TB
Donc oui, RA activé.
Du coup ca masque potentiellement les bugs avec les lectures de quelques secteurs ...
J’ai désactivé le RA et toujours pas d’erreurs. Je vais formater le VD en ext4 et le remplir pour voir si j’arrive à reproduire.
Raison pour lequel on part sur remplacement par de l’Intel.
Les micron 5300/7300 PRO/MAX ont aussi bonne réputation (pas testé, j'ai pas encore réussi a tuer les intel que j'ai), du moins pour ceph et postgresql.
Merci pour l’info, mais je tape plutôt dans le refurbished, et on voit pas trop Micron.
Ca peut etre une alternative, Intel est en train de sortir du marché des SSD (sauf pour Optane) et a revendu la techno a SK Hynix
Bonjour David, Le 25/03/2022 à 13:36, David Ponzone a écrit :
J’y ai pensé, mais si c’était le cas, ça commencerait à merder après le secteur X (X dans mon cas étant autour de 3028949248). Mais j’ai pu faire des lectures sans erreurs sur des secteurs après cette zone là.
Et pour répondre à Emmanuel hier, les IBM-SSG c’est du HGST Enterprise prévu pour 8 ou 10 écritures complètes par jour pendant des années, je sais pas où il est allé chercher que c’était du SSD GP :)
Pour avoir vécu deux ou trois trucs pas terribles sur le sujet, je dois reconnaitre que je suis assez prudent quand il s'agit de SSD, même dans les gammes "server". Concrètement, je reste sur certains modèles SSD qui ont fait leurs preuves sur les R730 et R740. Et concernant les gammes "Pro", "GP" ou approchant, elles sont bannies :-) Bon courage. -- *Emmanuel DECAEN* E-Mail: ed@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07
Bonne idée, mais quand tu mets la H730 en HBA, il n'y a plus rien de configurable et chaque PD est en Write Cache Disabled.
Le 22 mars 2022 à 08:08, Fabien <list@fgautreau.net> a écrit :
Hello,
As-tu regardé si tu avais plus d'infos/status dans les logs de l'IDRAC ?
Je ne sais pas si le mode HBA utilise la "battery cache" mais ça peut être une piste
participants (8)
-
David Ponzone -
Dominique Rousseau -
Emmanuel DECAEN -
Fabien -
Jarod G. -
Matic Vari -
Maxime De Berraly -
Vincent Tondellier