Re: [Gluster-users] Evergrowing distributed volume question

[Strahil Nikolov <hunter86_bg@xxxxxxxxx>]

Yes.

On Fri, Mar 19, 2021 at 19:14, Nux!

<nux@xxxxxxxxx> wrote:

So then, in theory my plan could work if I always rebalance.

Thanks

On 19 March 2021 17:12:07 GMT, Strahil Nikolov <hunter86_bg@xxxxxxxxx> wrote:

As gluster does not have metadata server, the client:s identify the brick via a special algorithm based on the file/dir name.

Each brick corresponds to a 'range' of hashes , thus when you add a new brick, you always need to rebalance the volume.

Best Regards,

Strahil Nikolov

Hello,

A while ago I attempted and failed to maintain an "evergrowing" storage

solution based on GlusterFS.

I was relying on a distributed non-replicated volume to host backups and

so on, in the idea that when it was close to full I would just add

another brick (server) and keep it going like that.

In reality what happened was that many of the writes were distributed to

the brick that was (in time) full, ending up with "out of space" errors,

despite having one or more bricks with plenty of space.

Can anyone advise whether current Glusterfs behaviour has improved in

this regard, ie does it check if a brick is full and redirect the

"write" to one that is not?

Regards,

Lucian

________

Community Meeting Calendar:

Schedule -

Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC

Bridge: https://meet.google.com/cpu-eiue-hvk

Gluster-users mailing list

Gluster-users@xxxxxxxxxxx

https://lists.gluster.org/mailman/listinfo/gluster-users

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------

Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk

Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel