On Sat, Jan 23, 2010 at 09:04:31AM -0800, Simon Breden wrote: > For resilvering to be required, I presume this will occur mostly in > the event of a mechanical failure. Soft failures like bad sectors > will presumably not require resilvering of the whole drive to occur, > as these types of error are probably easily fixable by re-writing > the bad sector(s) elsewhere using available parity data in redundant > arrays. So in this case larger capacities and resilvering time > shouldn't become an issue, right?
Correct. However, consider that it's actually the *heads* that contribute most to errors accumulating; over time they lose the ability to read with the same sensitivity, for example. Of course this shows up first in some areas of the platter that already had slightly more marginal surface quality. This is why smart and similar systems consider both the absolute number of bad sectors, as well as the rate of discovery, as predictors of device failure. > What might be a good idea for a backup box, is to use a large case > to house all your old drives using multiple matched drive-capacity > redundant vdevs. This way, each time you upgrade, you can still make > use of your old drives in your backup machine, without disturbing > the backup pool - i.e. simply adding a new vdev each time... This is basically my scheme at home - current generation drives are in service, the previous generation go in the backup pool, and the set before that become "backup tapes". Every so often the same thing happens with the servers/chassis/controller/housing stuff, too. It's coming up to time for exactly one of those changeovers now. I always have a bunch of "junk" data in the main pool that really isn't worth backing up, which helps deal with the size difference. There's no need to constantly add vdevs to the backup pool, just do replacement upgrades the same as you did with your primary pool. I, too, will admit to not being as diligent at putting the scheme into regular practice as theory would demand. I may also relocate the backup pool at a neigbours house soon (or, really, trade backup pool space with him). -- Dan.
pgpE5tTZyPXrY.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
