Would there be a way of doing this without broadcasting the request for file? how does gluster currently handle the file metadata at a low level? Is there a central or distributed metadata cache? Im sort of assuming there is some kind of full set of metadata which applies to the whole system but from what people have been saying this is not the case. How dows gluster work in this regard? 2008/5/16 Gordan Bobic <gordan@xxxxxxxxxx>: > Luke McGregor wrote: >> >> - we would like to retain the previous copy also as long as there is >> free space on the system and have references to both files if this is >> possible. The idea would be that over time the nodes which use files >> regularly would all have copies of the particular file, (obviously >> there is a synchronisation problem here but this could be worked >> around), when space is needed the least read copy should be deleted >> (assuming that it isnt the last copy). Does this make sense, im not >> sure i have explained it very well. > > It makes perfect sense. If this is always going to be in a LAN environment, > you could probably get away with broadcasting a request for a file and > seeing how many nodes respond. If you specify that you want redundancy of X > (X copies of files in the network), you could then delete the least recently > used local file when you are running out of space, provided that at least X > other nodes have the file in their local stores. > > In theory, as files migrate to local nodes, the number of broadcasts will > reduce, as most requests will be satisfiable locally. The downside is that > for each write, you'd have to find the peers with a copy of the file, and > send them the delta to update locally. Locking may become difficult, and > albeit doable, there may be some nasty race conditions to overcome. > > Gordan > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
