Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, because you have a cache pool and calculate the parity changes on a schedule, or when specific conditions are met, e.g., remaining available storage on the cache pool.

The cache pool is recommended to be mirrored for this reason (not many people see why I find this to be amusing).



And let me guess, the cache pool is suggested to be on an SSD?

> Increased perceived write speed: You will want a drive that is as fast as possible. For the fastest possible speed, you'll want an SSD

Great, now I have an SSD that is treated as a consummative and will die and need to be replaced. Oh and btw you are going to need two of them if you don't want to accidentally your data.

The alternative? Have the cache on a pair of spinning rust drives which will again be overloaded and are expected to fail earlier and need to be replaced while also having the benefit of being slow... But at least you won't have to go through a full rebuild after a cache drive failure.

Man, I am not sold on the cost savings of this approach at all... Let alone the complexity and moving parts that can fail...


> Great, now I have an SSD that is treated as a consummative and will die and need to be replaced.

It's only consumable if you hit the write limit. Hard drive arrays are usually not intended for tons of writes. SSDs $100 or less go up to at least 2000 terabytes written (WD Red SN700). How many hundreds of gigabytes of churn do you need per day?


Nobody has to rebuild after a cache drive failure. The data you would lose is the non moved data on the cache drive. You are really overthinking this with former knowledge that leads you to assumptions that are just not true.


But you’d have that problem on any system really.


Hit the comment depth limit again, but yes, SSDs!

Yes, Unraid can crash-and-burn in quite a lot of different ways. Ask me how I know! Why I'm all-in on ZFS now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: