You don’t have to be so dismissive. They complained for good reasons. If you read the actual topics you’ll find the IO stalled, the node got killed with OOM or the system has constant high IO wait, causing performance degradation.
Those aren’t small issues, so no, it’s not overblown. It’s a problem.
That’s a matter of scale… Storj doesn’t ever let the drive rest, even if it’s not at 100% utitlisation, that is still highly problematic for SMR drives.
They won’t be fine if the drive has already hit that wall and is using all its resources to rewrite the shingled tracks. You seem to still be missing the point of how hard that wall is you hit when an SMR drive is saturated.
Nope, they are not. They are based on actual experiences with this specific use case.
You’re using a sequential write test for these stats. A famously easy thing to do for SMR drives, because they don’t have to rewrite and reorganize a single track. And in that best case scenario, you already have significant drops in performance. Now imagine Storj, where lots of data is randomly deleted and rewritten. Leaving lots of gaps in the data and entire sections of shingled tracks needing to be rewritten in order to store a tiny file. And lots of those at the same time.
The test results you quit are meaningless for this use case.
I’m sorry… but this just shows you have no idea why an SMR disk filling up causes slow down. It has nothing to do with the edge of the platters. You should be so lucky that that’s all that would impact it.
Here’s a hint… This is an image a user posted of fragmentation of free space on a 10 month old node.
Original post here: Disk fragmentation is inevitable... Do we need to prepare? - #47 by JDA