On 08/03/2016 02:26, Mark Kirkwood wrote:
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).
Indeed, I should have been a bit more clear with my question.
What is swifts behavior of a situation in which a disk where a swift
partition points to runs out of space? There can be a number of swift
partitions that point to the same disk, does each partition gets a
certain capacity of the disk allocated?
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.
Anyone have any experiences around locking issues. I've seen comments
elsewhere that locking contention might be an issue for disk space used
for container and account rings.
regards
Mark
--
Regards,
Peter Brouwer, Principal Software Engineer,
Oracle Application Integration Engineering.
Phone: +44 1506 672767, Mobile +44 7720 598 226
E-Mail: peter.brou...@oracle.com
_______________________________________________
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
