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

2. case id==100

Max locks* per file <= 132

3. case id==10

Max locks* per file<= 488

 

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