Probably nothing symbolizes tradeoffs than RAID in software engineering
In RAID1 we wanted redundancy in case of disk failure, so the OS (or the RAID driver) would mirror block of data to multiple drives. This gives redundancy but slows down writes (you are essentially writing the same data twice and bound by the slowest drive). Here you only get 50% of the total drive space.
In RAID0 we wanted performance, so we would stripe the block and “smear” it across multiple devices, this way we get faster writes (same block is split in half and each half written in parallel) but if any device fails we lose our data. Great for temp caches and data you don’t care to lose. You get access to the entire two drive space.
Subsequent RAID systems are built on top of those two balancing, Performance vs Reliability vs Budget.
You will notice software engineers make these trade off all the time in the entire stack.
Hussein Nasser
Probably nothing symbolizes tradeoffs than RAID in software engineering
In RAID1 we wanted redundancy in case of disk failure, so the OS (or the RAID driver) would mirror block of data to multiple drives. This gives redundancy but slows down writes (you are essentially writing the same data twice and bound by the slowest drive). Here you only get 50% of the total drive space.
In RAID0 we wanted performance, so we would stripe the block and “smear” it across multiple devices, this way we get faster writes (same block is split in half and each half written in parallel) but if any device fails we lose our data. Great for temp caches and data you don’t care to lose. You get access to the entire two drive space.
Subsequent RAID systems are built on top of those two balancing, Performance vs Reliability vs Budget.
You will notice software engineers make these trade off all the time in the entire stack.
3 weeks ago | [YT] | 142