On Mon, Jan 25, 2010 at 04:08:04PM -0600, David Dyer-Bennet wrote: > > - Don't be afraid to dike out the optical drive, either for case > > space or available ports. [..] > > [..] Put the drive in an external USB case if you want, > > or leave it in the case connected via a USB bridge internally. > > It's for installs and rescues, mostly, which I still find more convenient > on DVD.
Yeah, me too sometimes - but they're just as good with the DVD connected via USB, while the freed up controller ports (and drive bay, if relevant) may offer additional convenience - like not needing to buy an extra controller yet. > I'm nearly certain to start with adding a third 2x400 mirror. The only > issue is two more drives spinning (and no way to ever reduce that; until > pool shrinking is implemented anyway). Not strictly true, especially if your replacement disks are at least twice the size of your originals (which is easy for 400's :-). You can use partitions or files on the larger disks, if shrinking is still not there yet at that future time. Ugly, sure, but it is a counterexample for "no way to ever". :-) > I see RAIDZ as a losing proposition for me. In an 8-bay box, the options > are 2 4-disk RAIDZ2 sets, which is 50% available space like a mirror but > requires me to upgrade in sets of 4 drives, and exposes me to errors > during resilver in the 4 drive replacements; or else an 8-drive RAIDZ2, > which does give me better available space, but now requires me to replace > in sets of *8* drives and be vulnerable through *8* resilver operations. > I don't like either option. Fair enough. Note that the "vulnerable" window is still a vulnerability to two extra failures - the second parity, plus the original data. There's always raidz3 :-) I got over the reluctance to do drive replacements in larger batches quite some time ago (well before there was zfs), though I can certainly sympathise. For me, drives bought incrementally never matched up (vendors change specs too often, especially for consumer units) and the previous matched set is still a useful matched backup set. > My backup scripts are a bit at risk from weird USB port issues with disk > naming as well. However, the namespace doesn't seem to have any > possibility of overlapping the names of the disks in hot-swap SATA > enclosures, so it can't overwrite any of them by any mechanism I can find. That's not really the issue I was referring to, though it's another risk. I was referring to the fact that the rpool may not import at boot time, with the usb stick in other than the slot it was originally created. I filed a bug for this ages ago, but can't find it right now. -- Dan.
pgpG6GnWiMi2Q.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
