[Gluster-users] some questions

[Jure Pečar]

Hello,

I'm evaluating gluster for web2.0ish infrastructure provider. I'm comparing it to mogilefs and Sun's project celeste. While each has its good and bad points, gluster looks the most impressive so far.

What I'm missing the most right now are: online reconfiguration and hot add/replace of bricks (storage nodes), different namespaces and/or quotas and something more than IP based authentication and authorization. I see some of those are in the roadmap already. Do you have any ETAs for future 1.x releases? What interests me the most is hot add & replace.

Is mixing of different sized bricks possible? From what I can see, only unify potentialy has problems with that.

What are the expirience with gluster server running on opensolaris zfs with stripe translators? Any issues with extended attributes?

I'm thinking ... is there a need for data checksumming on the wire, provided that tcp already does checksuming?

Right now unify and stripe translators are available ... have you thought about xor translators to implement something like raid5, raid6? Would this even make sense, if storage backend is filesystem?

Both celeste and mogile have a method to specify how many redundant copies shall each object (=file) have. Have you tought about implementing something like that? In that case raid thing would not be necessary.

As I understand things now, one needs to provide a separate server instance for each namespace one wants to provide. I think ZFS set a role model for how this should be done today. Are there any tehnical reasons you couldn't write a zfs like admin frontend to gluster?

Also, I find it a bit suprising that basically all the redundancy config is done on the client side. All that client should get is address and auth data to mount a volume, it should have no need to care about all the "implementation details". What decisions lead you to implement this on client side? I don't think HPC world is that much different from webhosting world in this regard.

Thanks for answers.


-- 

Jure Pečar
http://jure.pecar.org