No, I think this might confuse the users.
I think showing the info of the first server will be good because
of the reasons mentioned by you in the previous mail. Lets see
if we can come up with an ideal solution.
Krishna
any opinions?
My two cents worth :)
I'm not sure there is an easy way to do this, I was going to suggest the
size of the first volume is sufficient, because it holds at least one
copy of all the data, and when it fills up theres no more data that can
be held.
I realised the hole in this method when I though that there could be
another volume that is a smaller size than the primary volume, which
could fill up quicker, or rather every other volume is smaller than the
primary volume, which would leave with enough space on the primary
volume, but no space to replicate.
I then thought gluster should just show the size of the smallest drive,
but then if you don't replicate, say *.tmp files, and everything else,
and the smallest drive fills up, then if theres space on the primary
volume then the .tmp files should be stored there easily.
Perhaps the AFR translator can store some kind of time based accounting,
and provide an average value based on the way the afr is being stored.
E.g. if you are replicating *.html:3,*.tmp:1, and your drive is 90% tmp
files, then returning the value of the primary volume is sufficient.
However if the usage is 90% html files (hence all volumes are getting
this data) then returning the value of the smallest volume is appropriate.
I'm not a proponent of complexity, but I dont think there is a simple
global one solution for this. Perhaps it can be configurable in the
translator: something like....
option disk-size-reporting smallest
option disk-size-reporting primary
option disk-size-reporting dynamic # if implemented of course :)
Matt.
