[ 
https://issues.apache.org/jira/browse/AMQ-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526017#comment-15526017
 ] 

Tim Bain commented on AMQ-6441:
-------------------------------

I don't agree that there's nothing we can do, and I think this bug should be 
reopened.

One option would be to explicitly work around this particular use case, by 
assuming that if the long we get back from getTotalSpace() is negative, that 
means the filesystem is plenty big enough to hold the broker's data files.  
Obviously you can construct cases where the overflow will result in a small 
positive number and we'll still give the wrong answer, but the hack would still 
cover anyone with an 8EB filesystem (including the reporter of this bug).  16 
EB or any multiple thereof, however, would be a problem.

Another option would be to provide a config flag that allows you to skip the 
filesystem free space check, eliminating the problem entirely for all 
filesystem sizes when the flag is used.  We should do this at a minimum, 
whether or not we try to do hacks based on negative return values from 
getTotalSpace().

> Incorrect File System Size Reported with Amazon Elastic File System (EFS)
> -------------------------------------------------------------------------
>
>                 Key: AMQ-6441
>                 URL: https://issues.apache.org/jira/browse/AMQ-6441
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.11.1
>            Reporter: Ismail Bhana
>
> I've set up Active MQ in production with a shared file system master/slave 
> configuration (KahaDB). I've set everything up and mounted the EFS on both 
> EC2 instances. 
> When I check the disk free stats I get 8 exabytes for the shared file system: 
> {code}
> $ df -h 
> eu-west-1a.***.efs.eu-west-1.amazonaws.com:/  8.0E     0  8.0E   0% /mnt/efs 
> {code}
> Unfortunately, ActiveMQ cannot interpret this number (8 exabytes). This may 
> be due to integer truncation.
> Here is a snippet of the log:
> {code}
> Store limit is 102400 mb (current store usage is 0 mb). The data directory: 
> /mnt/efs/kahadb only has -8796093022208 mb of usable space - resetting to 
> maximum available disk space: -8796093022207 mb 
> Store limit is -8796093022207 mb, whilst the max journal file size for the 
> store is: 32 mb, the store will not accept any data when used. 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to