Review #551
closed
Orfeo: "sdb1: WRITE SAME failed. Manually zeroing.", branch: disable_write_same
Description
Orfeo, in /var/log/syslog:
Jun 11 13:44:58 orfeo kernel: [11104758.581132] sd 4:1:2:0: [sdb] Jun 11 13:44:58 orfeo kernel: [11104758.581192] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 13:44:58 orfeo kernel: [11104758.581252] sd 4:1:2:0: [sdb] Jun 11 13:44:58 orfeo kernel: [11104758.581301] Sense Key : Illegal Request [current] Jun 11 13:44:58 orfeo kernel: [11104758.581361] sd 4:1:2:0: [sdb] Jun 11 13:44:58 orfeo kernel: [11104758.581409] Add. Sense: No additional sense information Jun 11 13:44:59 orfeo kernel: [11104758.581469] sd 4:1:2:0: [sdb] CDB: Jun 11 13:44:59 orfeo kernel: [11104758.581518] Write Same(10): 41 00 00 30 64 9f 00 00 18 00 Jun 11 13:44:59 orfeo kernel: [11104758.581608] end_request: I/O error, dev sdb, sector 3171487 Jun 11 13:44:59 orfeo kernel: [11104758.581688] sdb1: WRITE SAME failed. Manually zeroing. [...] Jun 11 13:46:35 orfeo kernel: [11104855.008330] sd 4:1:2:0: [sdb] Jun 11 13:46:35 orfeo kernel: [11104855.008379] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 13:46:35 orfeo kernel: [11104855.008438] sd 4:1:2:0: [sdb] Jun 11 13:46:35 orfeo kernel: [11104855.008486] Sense Key : Illegal Request [current] Jun 11 13:46:35 orfeo kernel: [11104855.008545] sd 4:1:2:0: [sdb] Jun 11 13:46:35 orfeo kernel: [11104855.008593] Add. Sense: No additional sense information Jun 11 13:46:35 orfeo kernel: [11104855.008651] sd 4:1:2:0: [sdb] CDB: Jun 11 13:46:35 orfeo kernel: [11104855.008700] Write Same(10): 41 00 00 74 44 1f 00 00 08 00 Jun 11 13:46:35 orfeo kernel: [11104855.008795] sdb1: WRITE SAME failed. Manually zeroing.
The error seems to slow down the system (for example slapd was unavailable while this message was logged).
I guess we should apply this proposed solution: https://access.redhat.com/solutions/1394733.
Currently max_write_same_blocks is enabled for sdb.
Updated by Marc Dequènes almost 7 years ago
- Assignee set to Pierre-Louis Bonicoli
GOGOGO for the workaround.
Updated by Pierre-Louis Bonicoli almost 7 years ago
- Tracker changed from Bug to Review
- Subject changed from Orfeo: "sdb1: WRITE SAME failed. Manually zeroing." to Orfeo: "sdb1: WRITE SAME failed. Manually zeroing.", branch: disable_write_same
- Branch set to disable_write_same
Configuration has been updated on Orfeo.
Please, could you review disable_write_same branch ?
Updated by Marc Dequènes almost 7 years ago
Check applied configuration should set check_mode to no IIUC. I'm not used to this feature so maybe I'm mistaken.
The rest is totally fine to me, you can merge.
As for creating a module about this, I think we should not make little workaround-specific modules or that's going to be a pain in the ass to maintain. Nevertheless we could have a "disk" topic module in charge or setting hdparm/sdparm and all disk-related low-level settings. We can talk more about this on IRC. Whatever we choose to do I think we should first merge this PR to solve the problem, as this PR does not introduce any problem or future difficulty, and then take proper time to design the potential new module in a new PR.
Updated by Marc Dequènes almost 7 years ago
I have no idea why I can't change the status of this ticket. First time I'm not allowed to modify part of a ticket like this.
Updated by Pierre-Louis Bonicoli almost 7 years ago
- Status changed from New to In Progress
Marc Dequènes wrote:
Check applied configuration should set check_mode to no IIUC. I'm not used to this feature so maybe I'm mistaken.
The naming is very confusing but the documentation said:
Force a task to run in normal mode and make changes to the system, even when the playbook is called with --check. This is called check_mode: no.
The rest is totally fine to me, you can merge.
Ok
As for creating a module about this, I think we should not make little workaround-specific modules or that's going to be a pain in the ass to maintain. Nevertheless we could have a "disk" topic module in charge or setting hdparm/sdparm and all disk-related low-level settings. We can talk more about this on IRC. Whatever we choose to do I think we should first merge this PR to solve the problem, as this PR does not introduce any problem or future difficulty, and then take proper time to design the potential new module in a new PR.
Ok
I fixed a typo in ansible/roles/dc-base/defaults/main.yml: s/same_write_disabled/write_same_disabled/.
Updated by Pierre-Louis Bonicoli almost 7 years ago
- Status changed from In Progress to Resolved
Merged.