On 06/03/16 21:15, Peter Brouwer wrote:
Interesting info. Two followup questions, Can the ring builder cope with a disk that is dynamic in size, like an nfs share from a storage array in which an nfs share shares capacity from a pool, i.e. If an other share in that pool takes up space the nfs share used by swift decrease in capacity. So the thing Im trying to understand is how swift/ringbuilder checks if a disk in a ring is running out of space?
Well, you build the ring 'offline' and distribute the resulting files (object.ring.gz etc) to all the hosts in your Swift cluster. So the ring-builder binary does not have any idea about the free space available on a device (the builder - you - just plugs the weights in).
Once Swift is up and running, you can check the state of things with swift-recon - which does know about free space, but I think a device that can *decrease* in capacity is not an ideal choice(!) - usual practice is to use a (real) disk dedicated to Swift storage.
Additionally attaching devices via nfs is less than ideal too (adding additional network latency for one thing), and will make less useful some of Swift's locality optimisations (e.g affinity...since a host's nfs mounted 'device' might not actually be close to it)! Also nfs general vagueness regarding file locking and syncing make it seem like a bad choice overall.
regards Mark _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
