Ik wilde graag nog even voortborduren op dit topic:
Continue device resets SATA disks op SAS-controller+expander
Hierin vroeg ik om hulp met voortdurende device resets, en Ben(V) gaf me die door te suggereren dat de problemen veroorzaakt werden door mijn gebruik van SMR schijven.
Nu las ik onlangs nav. deze issues een artikeltje dat stelde dat SMR-drives blijven, en dat je kunt verwachten dat je ze ook steeds vaker in enterprise storage oplossingen zult vinden: de vraag naar ruimte blijft tenslotte toenemen, en HDD's zijn vooralsnog een stuk goedkoper dan SDD's. Dat bewoog me om eens te kijken of ik alsnog iets kan doen met het stapeltje SMR-schijven die ik heb liggen.
Wat specifieker, de volgende twee vragen:
1. Is er een manier om de timeout dit in dit stukje logging wordt vermeld
2. Ik heb gekeken naar de max_sector en max_queue_depth parameters van de mpt3sas-driver, en ik heb het gevoel dat de frequentie van timeouts iets minder wordt als ik deze parameters laag houd, maar zijn er nog andere parameters die ik kan tunen om een ZFS array toleranter te maken jegens de lange write-times die SMR-schijven veroorzaken?
Dank!
Continue device resets SATA disks op SAS-controller+expander
Hierin vroeg ik om hulp met voortdurende device resets, en Ben(V) gaf me die door te suggereren dat de problemen veroorzaakt werden door mijn gebruik van SMR schijven.
Nu las ik onlangs nav. deze issues een artikeltje dat stelde dat SMR-drives blijven, en dat je kunt verwachten dat je ze ook steeds vaker in enterprise storage oplossingen zult vinden: de vraag naar ruimte blijft tenslotte toenemen, en HDD's zijn vooralsnog een stuk goedkoper dan SDD's. Dat bewoog me om eens te kijken of ik alsnog iets kan doen met het stapeltje SMR-schijven die ik heb liggen.
Wat specifieker, de volgende twee vragen:
1. Is er een manier om de timeout dit in dit stukje logging wordt vermeld
code:
te verhogen? Ik heb geprobeerd de setting te vinden in de SAS-controller BIOS, maar na het verdubbelen van alle timeout-attributen krijg ik nog steeds dezelfde melding.1
| Jul 28 02:03:48 nas kernel: sd 8:0:27:0: attempting task abort!scmd(0x0000000054eb3936), outstanding for 1016 ms & timeout 1000 ms |
2. Ik heb gekeken naar de max_sector en max_queue_depth parameters van de mpt3sas-driver, en ik heb het gevoel dat de frequentie van timeouts iets minder wordt als ik deze parameters laag houd, maar zijn er nog andere parameters die ik kan tunen om een ZFS array toleranter te maken jegens de lange write-times die SMR-schijven veroorzaken?
Dank!