Skip to content
This repository was archived by the owner on Oct 30, 2018. It is now read-only.

Optimize for SMR tech drives & Raid 5/6 backed storage #32

Closed
1credit opened this issue Oct 16, 2016 · 1 comment
Closed

Optimize for SMR tech drives & Raid 5/6 backed storage #32

1credit opened this issue Oct 16, 2016 · 1 comment

Comments

@1credit
Copy link

1credit commented 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.

@1credit 1credit changed the title Optimize for SMR tech drives Optimize for SMR tech drives & Raid 5/6 backed storage Oct 16, 2016
@161chihuahuas
Copy link
Contributor

This feature request is better suited at the EmbeddedStorageAdapter layer in storj-lib (core). If you'd like to open it there, feel free

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants