at 11:48, Uwe Schindler wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> in general you can still use MMapDirectory. There is no requirement to
>>>>>>>> set vm.max_map_count
s with NFS or SMB.
We are experiencing recurring index corruption, specifically a "read past EOF"
exception. I asked on the Elastic Search forum but the answer I got was a bit generic and
not really helpful other than confirming that, from ES point of view, ES should work on
an SMB shar
19 and you use
>>>>>> `--enable-preview` in you jvm.properties file, you don't even need to
>>>>>> change that setting even with larger clusters.
>>>>>>
>>>>>> Uwe
>>>>>>
>>>>>&
or SMB.
We are experiencing recurring index corruption, specifically a "read past EOF"
exception. I asked on the Elastic Search forum but the answer I got was a bit generic and
not really helpful other than confirming that, from ES point of view, ES should work on
an SMB share as long
uster is made up
>>>>> of 4 nodes, each one have a separate file share to store the indices.
>>>>>
>>>>> This configuration has been influenced by some ACIs limitations,
>>>>> specifically:
>>>>>
>>>>> we cannot
e a separate file share to store the indices.
>>>>
>>>> This configuration has been influenced by some ACIs limitations,
>>>> specifically:
>>>>
>>>> we cannot set the max_map_count value as we do not have access to the
>>>
he
>>>> underlying host
>>>> (https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html).
>>>> Unfortunately, this is required to run an ES cluster, therefore we were
>>>> forced to use NIOF
>>>> ACI’s storage
ephemera, therefore we had to map volumes to persist the
indexes. ACIs only allow volume mappings using Azure File Shares, which only
works with NFS or SMB.
We are experiencing recurring index corruption, specifically a "read past EOF"
exception. I asked on the Elastic Search forum bu
co/guide/en/elasticsearch/reference/current/vm-max-map-count.html).
>> Unfortunately, this is required to run an ES cluster, therefore we were
>> forced to use NIOF
>> ACI’s storage is ephemera, therefore we had to map volumes to persist the
>> indexes. ACIs onl
d to run an ES cluster, therefore we were
> forced to use NIOF
> ACI’s storage is ephemera, therefore we had to map volumes to persist the
> indexes. ACIs only allow volume mappings using Azure File Shares, which only
> works with NFS or SMB.
>
> We are experiencing recurring in
s ephemera, therefore we had to map volumes to persist the
>> indexes. ACIs only allow volume mappings using Azure File Shares, which only
>> works with NFS or SMB.
>>
>> We are experiencing recurring index corruption, specifically a "read past
>> EOF" exc
File Shares, which only
works with NFS or SMB.
We are experiencing recurring index corruption, specifically a "read past EOF"
exception. I asked on the Elastic Search forum but the answer I got was a bit generic and
not really helpful other than confirming that, from ES point of view,
, therefore we were forced
to use NIOF
ACI’s storage is ephemera, therefore we had to map volumes to persist the
indexes. ACIs only allow volume mappings using Azure File Shares, which only
works with NFS or SMB.
We are experiencing recurring index corruption, specifically a "read pas
13 matches
Mail list logo
