On 01/28/2013 04:58 PM, Alexandros Soumplis wrote: > You mention "The way this is supposed to work is that if a brick is > full then *new* files will be created on other bricks with more > space.". I am not quite sure that this is the case when the new file > is large enough to fill up the space of the chosen brick, while it > would fit on another. 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.
