On 8/10/07, Darren J Moffat <[EMAIL PROTECTED]> wrote: > Tuomas Leikola wrote: > >>>> We call that a "mirror" :-) > >>>> > >>> Mirror and raidz suffer from the classic blockdevice abstraction > >>> problem in that they need disks of equal size. > >> Not that I'm aware of. Mirror and raid-z will simply use the smallest > >> size of your available disks. > >> > > > > Exactly. The rest is not usable. > > For what you are asking, forcing ditto blocks on to separate vdevs, to > work you effectively end up with the same restriction as mirroing.
In theory, correct. In practice, administration is much simpler when there are multiple devices. Simplicity of administration really being the point here - sorry I didn't make it clear at first. I'm skipping the two-disk example as trivial - which it is. Howerer: administration becomes a real mess when you have multiple (say, 10) disks, all differing sizes, and want to use all the space - think about the home user with a constrained budget or just a huge pile of random oldish disk lying around. It is possible to merge disks before (or after) setting up the mirrors, but it is a tedious job, especially when you start replacing small disks one by one with larger ones, etc. This can be - relatively easily - automated by zfs block allocation strategies and this is why I consider it a worthwhile feature. > However I suspect you will say that unlike mirroring only some of your > datasets will have ditto blocks turned on. > That's one good point. Maybe I don't want to decide in advance how much mirrored storage i really need - or just use all the "free" mirrored space for nonmirrored temporary storage. I'd call this flexibility. > The only way I could see this working is if *all* datasets that have > copies > 1 were "quotaed" down to the size of the smallest disk. > Admittedly, in the two-disk scenario the benefit is relatively low, but in the most multi-disk scenarios the disks can be practically full before running out of ditto locations - minus the block(s). (This holds for copies=2 if largest disk < sum of others). > Which basically ends up back at a real mirror or a really hard to > understand system IMO. I find volume manager mess hard to understand - and it is a mess in the multidisk scenario when you start adding and removing disks. For a real-world use case, i'll present my home fileserver. 11 disks, sizes vary between 80 and 400 gigabytes. The disks are concatenated together into 6 "stacks" that are raid6:d together - with only 40G or so "wasted" space. I had to write a program to optimize the disk arrangement. Raid6 isn't exactly mirroring, but the administrative hurdles are the same. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
