You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 30, 2018. It is now read-only.
Storj is a read-mostly application with archive like characteristics (write data once, store for a long time, maybe read back). This type of application screams for archive class data storage, like those that utilize SMR (Shingled Magnetic Recording) for cost effectiveness. SMR drives suffer from random write performance issues but are very cost effective.
Please consider adding an option to "Copy on Commit", where when a data transfer is starting, a seperate temporary area (perhaps on a write friendly drive like an SSD) would be utilized until the entire ldb file is received, after which it is copied to the bulk storage (using sequential write I/Os by the nature of such a copy). This would significantly improve the performance of any SMR class drive as well any Raid 5 or Raid 6 implementations where entire stripe sets oculd be written, reducing Raid 6 I/O by as much as 4X.
The text was updated successfully, but these errors were encountered:
1credit
changed the title
Optimize for SMR tech drives
Optimize for SMR tech drives & Raid 5/6 backed storage
Oct 16, 2016
Storj is a read-mostly application with archive like characteristics (write data once, store for a long time, maybe read back). This type of application screams for archive class data storage, like those that utilize SMR (Shingled Magnetic Recording) for cost effectiveness. SMR drives suffer from random write performance issues but are very cost effective.
Please consider adding an option to "Copy on Commit", where when a data transfer is starting, a seperate temporary area (perhaps on a write friendly drive like an SSD) would be utilized until the entire ldb file is received, after which it is copied to the bulk storage (using sequential write I/Os by the nature of such a copy). This would significantly improve the performance of any SMR class drive as well any Raid 5 or Raid 6 implementations where entire stripe sets oculd be written, reducing Raid 6 I/O by as much as 4X.
The text was updated successfully, but these errors were encountered: