Re: Concatenation with redundancy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7-Sep-04, at 2:09 PM, Guy wrote:

I can see how this would be useful.
Being able to add disks over time, and of different sizes.
The parity disk would be the biggest.
Disks tend to get larger over time. So, when you add a disk it will tend to
be larger than any of the others. The current parity would be re-used to
extend the size, and the new disk would become the new parity.

Exactly.


What would happen when you replace a failed disk with a new larger disk?
Just waste the extra space?

Probably, but it's easy to find small disks on eBay and the like. It's no worse than replacing a failed drive in a homogeneous array.



The performance would not be too good. Like raid5 on a real real bad day!

That's true. However, writes would be fairly rare for the application of a media library, with most of the accesses being read-only.



I don't like concatenated disks. You can't balance the load on the drives.
I would never use this feature if it did exist. But, some would love it I
bet.

It's much easier to add space to a concatenated set though, and single drive performance is easily sufficient for the media library application.



Cheers - Tony 'Nicoya' Mantler :)

--
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@xxxxxx
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux