Wandering Thoughts archives


Why we're interested in many ZFS pools

I wrote up our basic fileserver design plan back in ZFSFileserverDesign, but it is worth explaining why we are looking at using many pools. In a nutshell:

Given that we sell fixed size chunks of space to people (as the way we allocate our storage space), we are always going to have a certain number of logical pools of storage to manage. The only question is whether to handle them as separate ZFS pools or to aggregate them into fewer ZFS pools and then administer them as sub-hierarchies using quotas. Our current belief is that it's simpler to use separate pools; there is one less thing to keep track of when you add space, you avoid the possibility of certain sorts of stupid errors, and it is simpler to explain to users.

(In our situation it also lessens the amount of data we'd lose if we lost both disks in a mirrored pair.)

We're unlikely to normally have, say, 132 pools on a single fileserver. However, we are going to have a failover environment, which means that we may sometimes have to limp along with the pools from several fileservers temporarily all running on to one machine. Figuring out the limits in advance may save us a lot of heartburn during a crisis.

(Plus, learning about this stuff helps us plan out the fileservers and how to split groups and people between them, and so on.)

solaris/WhyManyZFSPools written at 00:05:02; Add Comment

By day for May 2008: 1 2 3 4 5 6 7 8 9 11 12 13 15 17 18 19 20 21 23 24 25 26 28 29 30 31; before May; after May.

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.