Elastifile Cloud File System - NLM Limitations

Updated to version 3.2.1.x

Introduction

Elastifile Cloud File System supports advisory file locking, lock requests and partial range locks per file.

As with every system resources the resources that are allocated to this functionality are limited and in certain scenarios can impact the customer environment.

The following document describes these limitations


Connection per system frontend cores

Each storage node's cores are evenly split into frontend and backend cores. Frontend cores are responsible for client connection termination, protocol termination and file locks functionality.

While each node can handle up to 1000 clients connections, if locking functionality is uses the actual number of connections is limited as follows:

There is a limit of 100 client connections (ip address granularity) per core.

-- blocking locks - resource (pool) that is being taken for maintaining a list of clients that are pending for a lock to be released - up to 100 connections from different client IP addresses.

-- non-blocking locks - there is a small time period where this resource is being taken (before parsing the lock request), however it is released when replying to the client. limit of 100 concurrent requests from different client IP addresses. 

 

In terms of different nodes configurations in GCP the limitations per nodes are as follows

Configuration

Instance Type

# CPUs

# FE cors

Concurrent request or concurrent  waiters for Blocking locks

Concurrent requests for Non-Blocking locks

Small (Persistent-SSD)

Custom

4

2

200

200

Medium (Persistent-SSD)

Custom

4

2

200

200

Medium Plus (Persistent-SSD)

Custom

8

4

400

400

Large (Persistent-SSD)

N1-highmem 16

16

8

800

800

Local SSD

Custom

16

8

800

800

Small Local SSD

Custom

4

2

200

200

Standard PDs*

Custom

4

2

200

200

Small Standard PDs*

Custom

4

2

200

200

* These configurations are not for production and will be removed in following versions



Number of active locks per file

For each file there is an aux file that holds the current active locks on the file. The file limit is 32KB and the number of locks it can hold depends on the identification of the locking client and the locking application.

The formula for the file structure is as follows

Lock entry = 11

+ for each holder: 43 + owner (identify owner of a lock)  + caller_name - Holder is a client currently holding a lock

+ for each waiter: 47 + owner (identify owner of a lock)  + caller_name - Waiter is a client waiting for a lock request approval for an already locked file or range

+ for each share: 28 + owner (identify owner of a lock)  + caller_name - Share reservation for the entire file

 

caller_name is usually the hostname, the owner is usually pid@hostname and the Client ID or Application ID can't be longer than 1024 

For example

In the example below twe assume the caller_name and owner ID are the same lengths. And the number of max locks is taken as the worst case of all waiters. The actual number of possible locks is in between the numbers in the example.

  1. worst case id==1024

Max locks* per file <= 15

  1. case id==100

Max locks* per file <= 132

  1. case id==10

Max locks* per file<= 488

 

The sum of locks in any of the stages - holders, waiters or shares

D
Dadee is the author of this solution article.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.