FileStore overflow for 8 exabytes filesystem

[Francis Galiegue]

In my view, and given the documentation, this is clearly a bug.

While the documentation doesn't mention any specific behavior, I have
developed filesystems of my own; and AFAIR, the recommendation when
the underlying FileStore was unable to return a usable value was to
return Long.MAX_VALUE.

Here, you seem to be using a mount on a Unix filesystem hierarchy,
which only makes things worse. For any metadata, you have two
indirection: from EFS to someUnix and from someUnix to the Java API.
That does not help matters.

Ideally, you want a direct JSR 203 bind to EFS. This will likely solve
all your problems in one go.


On Tue, Jul 26, 2016 at 12:03 AM, Robert Muir <rcmuir at gmail.com> wrote:
> Hello,
>
> We had a user report this interesting one with amazon EFS:
>
> https://discuss.elastic.co/t/elasticsearch-with-amazon-elastic-file-system/55867/8
>
> FileStore.java overflows here, all the methods look like this:
>
>     @Override
>     public long getUsableSpace() throws IOException {
>        UnixFileStoreAttributes attrs = readAttributes();
>        return attrs.blockSize() * attrs.availableBlocks();
>     }
>
> the original blockSize and various block counts are unsigned 64 bit
> values, but they are treated as signed longs, then multiplied, and
> then it causes negative numbers reported back via FileStore.
>
> What can be done? It seems FileStore API is hopelessly broken since it
> returns long, and returns bytes. treating it as unsigned long wouldn't
> be that much better...
>
> Should I open a bug?



-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa