Thank you for the reply, Maybe then, would it be possible to implement a patch for the distribute translator so as to a) Check for a file if there is a previously failed action within a specified time period b) If the failed action is due insufficient space on a brick try to place it to another brick hoping for the best a. On 29/01/2013 12:23 ??, Jeff Darcy wrote: > Well, we can't know how large a file is going to be when it's first > created. All we know is that the user asked us to create it, and that > the brick we'd normally choose (via the elastic hashing algorithm) is or > is not full. Sometimes it turns out that we would have been better off > creating the file somewhere else. Because we can't go back in time and > change where we already wrote data, the best we could do would be to > relocate the file as it's still being written, but that's a lot more > difficult than relocating inactive files to make room. > > The min-free-disk options can be used to create more of a buffer between > when we start treating a disk as full and when we have no choice but to > return an error, to allow more time for such corrective action. Even > so, it's still a good idea to monitor usage and prune or rebalance files > manually sometimes. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users
