2009/1/13 Dan Parsons <dparsons@xxxxxxxx>: > I'm following the directions on this page: > > http://www.gluster.org/docs/index.php/Advanced_Striping_with_GlusterFS_2.0 > > Following the above directions, you have a dht volume and a stripe volume > joined together via unify. When mounting that unify volume, df reports twice > the actual available capacity. If I remove one of the dht/stripe volumes > from the unify volume, df reports normal disk usage. So, I can understand > why this is happening (gluster sees two separate volumes) but as the same > group of servers host the dht & stripe volumes, the actual space is half > what gluster thinks it is. Is this the intended behavior? I think it works as good as possible - it does everything as it should but still gives the wrong number. To correct that, all translators that aggregate space (dht, unify, stripe) would have to be aware of all the layers below them and of any dual use of free space. I think that might make it very complicated to calculate it right in all cases. Having an option to apply a factor to the free space report would help in some cases of obvious miscalculation. In other cases (e.g. using only three of the dht subvolumes but using all four stripe volumes from the example) it would lead to wrong numbers. > My end-goal here is to be able to have some files dht'd and some striped. > This seems to be the best way to do it, if I'm wrong please let me know. I don't know any options you could change to get a better result. Mounting the dht and stripe volumes on two different mountpoints would move the point of error to the user. 'df' would report two volumes having free space and the user would have to know that it actually is the same free space that he/she is seeing. And then "management" comes along and says: "Do we really need all these extra disks?" :-) I think I'd try to use two different mountpoints if possible as it would make it easier to understand that one of them has a much higher risk of failure due to the striping. Harald Stürzebecher
