Skip to content
This repository was archived by the owner on Feb 8, 2024. It is now read-only.

m0 pools profiles

Valery V. Vorotyntsev edited this page Oct 14, 2020 · 1 revision

Motr pools and profiles

We have all those disks to store data on. Disks are put into disk enclosures which, in turn, are arranged in racks.

Motr I/O services stripe data across disks. Striping improves I/O performance and makes the system more resilient — if one disk fails, its data can be restored elsewhere. We want to stripe parity groups [HLD-SNS] not only across disks, but across disk enclosures as well, in order to avoid data loss in case some enclosure gets disconnected or powered off. Motr uses parity declustering striping algorithm.

Motr works with pools of storage devices. Parameters of parity declustering, such as how many data units and parity units are there in a parity group, are defined per pool.

Pools refer to non-overlapping sets of disks.

Profile is a reference to one or more pools.

When Motr client is started, it receives profile fid from the command line. Motr client will only be able to use those pools which are referred to by its profile.

Multiple pools

Some uses of multiple pools:

  • Distribute pools between groups of users. When users work with different pools, they are less likely to overwrite each other's data.
  • Use various striping patterns: 8+2 for one pool, 16+2 for another, etc.
  • Hardware addition (aka "scale out") — new disks form new pool.

Motr configuration schema

m0conf-schema.png

References

Clone this wiki locally