Request for "read-only" translator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



With glusterfs 1.3 getting close to a releasable state, I started thinking
about the structure of a global namespace for our applications.
There will be "mirrored machines" (AFR) for crucial data, and there should
be part of the servers offering read-only stuff (making sure nothing gets
added to the filesystem) perhaps also on top of an AFR layer (for the
super important, time critical input data repositories).
This results in the following structure (with individual "units" in varying
counts):

brick1a
      > AFR (mirror) > readonly
brick1b                          \
                                 |
brick2a                          |
      > AFR (mirror) > readonly  |
brick2b                           > unify
                                 |
brick3 (AFR if I'm paranoid)     |
brick4 (can be AFR)              |
brick5 (can be AFR)              /
...

(Apologies for the ASCII graphics.)

Bricks 1 and 2 (which come in two copies) would store the "never lose this"
stuff while it's still possible to work (store new data) on the other bricks.

Of course, two features are essential for such a setup:
- a "readonly" xlator (does the "filter" xlator yield this? couldn't find
	anything about "option" syntax)
- a "unify" xlator which can handle read-only subvolumes (can it already?
	does this have an influence on the choice for schedulers?)

Is there someone who already implemented this to some extent and is willing
to share her/his config? Any suggestions which scheduler to choose?

Cheers,
 Steffen

-- 
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html





[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux