[Gluster-devel] Improving real world performance by moving files closer to their target workloads

[Luke McGregor]

Hi everyone

I think i misunderstood the way you were proposing implementing a quorum. I
thought there was no state data stored. Let me just confirm how you were
proposing to implement this.

- (client) A node requests a write to a specific file and broadcasts this to
the network
- (server) the server checks that no other nodes are claiming a lock on that
file and replies accordingly if file was lockable the server locks it
- (client) The node then waits for 50% + 1 node to respond and say that they
can write.
- (client) The node writes the file
- (client) The node broadcasts a file completed message.
- (server) Updates its locking database to free that file

Does this look correct? If so i have a few questions.

Is there any information stored by nodes on who is writing the file? (if so
what happens when the lock fails? wont the above model lock the file on
nodes which have no current lock but not actually hold the lock ie node1
requests but node2 has lock wont some servers have granted lock to node1 and
have that info stored) If this is not the case what happens if some servers
dont recieve the un-lock broadcast? wont they still think that the file is
locked and respond on that basis the next time they are in a quorum?

If we assume the simplest possible solution where there is at least one copy
of each file required, how would you identify a file which can be deleted on
the system without having to broadcast a query on every single file starting
from the oldest?

Obviously i agree that distributed metadata is a really good thing to have
for scalability and reliability. However i am worried that the whole
broadcasting side of things is going to cause some huge problems in
implementing our migration project. im especially worried about how to solve
the old file problem. im also worried that every server in the network is
going to have to hold a fairly sizable set of metadata, this seems to be a
problem in terms of scaling.

If im wrong on any of these points correction would be greatly appreciated,
i still dont think i understand what your proposing in terms of a quorum.

Thanks
Luke