###Storage Policy configurations All glusterfs volumes as a single storage policy with each volume being just a device to Swift: In this case, Swift hashes and chooses where to place objects into. Hence PUT of an object can go to either of the volumes. For example, if we have two glusterfs volumes test and test2, putting ten objects (named 1 to 10) into AUTH_abc account and container cg (marked with sp glusterfs) can look like so on mountpoint:
curl -i http://vm1:8080/v1/AUTH_abc/cg -X PUT -H 'X-Storage-Policy: glusterfs'
curl -i http://vm1:8080/v1/AUTH_abc/cg/o{1..10} -X PUT -d'testobject'
/mnt/gluster-object/test
└── abc
└── cg
├── o1
├── o10
├── o2
├── o3
├── o4
├── o6
└── o8
2 directories, 7 files
/mnt/gluster-object/test2
└── abc
└── cg
├── o5
├── o7
└── o9
2 directories, 3 files
Implications of this config: For usecases where user wants file-system access to objects PUT via Swift, he has to go through each of the devices/volumes looking for the object! This is because objects and containers in one account need not physically reside in same volume/device.
Each glusterfs volume as a separate storage policy In this case, the client can specify which specific glusters volume/device the object can go into. For usecases where user wants file-system access to objects PUT via Swift, he'll know which volume/device has the objects that he's looking for.
- Which of the above two configurations is recommended ?
- What value does swiftonfile project add to Swift if used with XFS as backend and not glusterfs ? Only a more human friendly the path and name of object ?
- Where does GlusterFS specific libgfapi-python consumption fit in swiftonfile project ?
- Swiftonfile can be of real value when it can offer things like multi protocol access and also usecase that Luis once mentioned - just place swiftonfile on existing NFS/filesystem and it should export it as object store.