| rrq | anyone with raid expereince? Is "higher" process priority (-5) important/good/irrelevant/bad for the raid resync ? (It takes about 4 hours for 1.8 TB at -5 priority.) | 03:27 |
|---|---|---|
| xrogaan | you shouldn't use your drive with it sync | 04:09 |
| xrogaan | it's not really a matter of priority, so long you have cpu cycles to spare. | 04:09 |
| xrogaan | The high priority will put your task on top of other tasks in the scheduler queue. But if your cpu is mostly idle, it doesn't really matter. | 04:11 |
| xrogaan | Basically, it's good to put critical tasks on high priority when your computer is very busy. Otherwise, it doesn't matter. | 04:12 |
| onefang | Might be worth looking at ionice. | 04:16 |
| xrogaan | Well, it's a drive task. ionice would be high, probably. | 04:18 |
| xrogaan | Your raid drives will need to read data to let the new one reconstruct. That can only go as fast as your drives are. | 04:18 |
| xrogaan | I might not have understood what resyncing means though. | 04:20 |
| xrogaan | I was assuming that you had to replace a disk. But adding a new one on top can leave the computer usable. | 04:20 |
| xrogaan | From what I read, the reconstruction is then throttled by limiting the I/O bandwidth. | 04:21 |
| bb|hcb | I don't think touching the prio/ioprio is a good idea; there are two sysctl: dev.raid.speed_limit_max and dev.raid.speed_limit_min | 04:28 |
| bb|hcb | Increasing _max is fine, touching _min is also not good - the bigger the min, the bigger the impact from sync on the load | 04:29 |
| LeePen | Just pushed some more updates to Release Notes. | 11:56 |
| LeePen | https://git.devuan.org/devuan/documentation/src/branch/wip/chimaera_release_notes.md/release-docs/Release_notes_chimaera_4.0.0.md | 11:56 |
| LeePen | Comments welcome. | 11:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!