Why we're interested in many ZFS pools

May 17, 2008

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.)

Written on 17 May 2008.
« Why it is hard to decommission a DNS blocklist
Counterproductive password security »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat May 17 00:05:02 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.