Avi Kivity wrote:
Ric Wheeler wrote:
One key is not to replace the drives too early - you often can
recover significant amounts of data from a drive that is on its last
legs. This can be useful even in RAID rebuilds since with today's
enormous drive capacities, you might hit a latent error during the
rebuild on one of the presumed healthy drives.
Of course, if you don't have a spare drive in your configuration,
this is not practical...
Why would you have a spare drive? That's a wasted spindle.
You have a spare drive because you care about data integrity and have
too many years of experience in disk arrays to go without :-)
You want to have spare capacity, enough for one or two (or fifteen)
drives' worth of data. When a drive goes bad, you rebuild into the
spare capacity you have.
That is a different model (and one that makes sense, we used that in
Centera for object level protection schemes). It is a nice model as
well, but not how most storage works today.
When you replace the drive, the filesystem moves data into the new
drive to take advantage of the new spindle.
When you buy a storage solution (hardware or software), the key here is
"utilized capacity." If you have an enclosure that can host say 12-15
drives in a 2U enclosure, people normally leave one drive as spare.
RAID6 is another way to do this. You can do a 4+2 and 4+2 with 66%
utilized capacity in RAID 6 or possibly a RAID5 scheme using like 5+1
and 4+1 with one global spare (75% utilized capacity).
That gives you the chance to do rebuild your RAID group without having
to physically visit the data center. You can also do fancy stuff with
the spare (like migrate as many blocks as possible before the RAID
rebuild to that spare) which reduces your exposure to the 2nd drive
failure and speeds up your rebuild time.
In the end, whether you use a block based RAID solution or an object
based solution, you just need to figure out how to balance your utilized
capacity against performance and data integrity needs.
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
