9:08 a.m.
On 12/4/15 6:41 AM, Emmanuel Hugonnet wrote:
Keeping only the relevant parts, remarks inlined :
>> * for space availability this might depend on the different mount points:
>> - should we provide it for every path since we wouldn't know in
advance to which mount point each path is on
>
> I don't understand this question. How were you planning to get the space
> availability information?
>
> My instinct is the closer this conforms to what the standard java (n)io
> API provides the better.
>
What I mean is that since we don't know to which mount point/drive each path is
using, we would have to define the space availability per
path instead of as a global metric/value.
I don't think we should try to do any kind of aggregation or analytical
work. A path resolves to a File and a File reports getUsableSpace(). If
a user looks at two paths on the same partition and double counts by
assuming he can use that much for each path, that's a user error. But
it's kind of a "duh" kind of error, so long as we document the semantic
(including a reference to the JDK javadoc we rely upon) and are careful
about how the data is presented in any UI. The UI is probably the bigger
problem.
So I was wondering if this is really something that makes sense.
Which explains the next question aka are these informations valuable.
That I don't know, but it seems useful. It provides information that a a
user can then reason with, either well or poorly. It's not rocket
science to reason intelligently though.
I rarely object to not including something that hasn't been specifically
asked for though, so I don't mind not including this if no one makes a
case for it.
>> - or maybe this info is not that important
>>
Cheers,
Emmanuel
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat