Hi Antonio, replies inline... On Thu, Apr 3, 2008 at 9:20 PM, Antonio González <antonio.gonzalez@xxxxxxxxxx> wrote: > > > Hello all, > > > > First, Sorry for my English, I try to write my question the best possible…. > > > > I am making some tests with the cluster/afr translator, my scenario are > three machines, the first exports one brick for storage, the second exports > one brick for replicates and the third exports the cluster/afr. The firs > machine is the client. The problem is, the second machine has very little > space disk, then when I try to copy a file (8 MB) in the file system > (glusterfs), at the first machine, the copy process finishes correctly but > at the second server the file has only 1,6 MB, the problem is if I try to > exec the file from the client (vlc, the file is a .mov file) the read fails. > > > > If I switch off the second server and repeat the same test I can see the > movie perfectly. If I return to turn on the second server the problem > persist. > > > > I know that the reads in AFR has always the same destination (server cache > advantage), I think that in this case the destination of the .mov file is > the second server, where the .mov file is incorrect… > Correct. > > > How I can to prevent this situation?? There is some mechanism to detect when > a server is full??? Ideally afr's subvolumes should have same storage space. "df" shows the disk usage of the first subvolume, if the other subvolumes are of the same size then you will know the space of those volumes too. When they are different you have to go to the backend storage space and check manually the available space and make suitable arrangements to get more space. In future though, when we have a management interface we can create an "alert" when the disks runs out of space. I think we can provide an option which when enabled the afr returns error when one of the calls to the subvols return "out of disk space" error. I will put this in TODO list. Regards Krishna > > > > Thanks….and sorry for my English!!! > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
