Cybersecurity
DevOps Cloud (ADM)
IT Operations Cloud
Beginning with the OES 2015 SP1 release, the NSS file system has improved disk storage allocation policies. This improvement in disk storage allocation is referred to as delayed block allocation.
Delayed block allocation improves the file system performance and reduces the file fragmentation by effectively writing larger amounts of data at a time. Delayed block allocation allows the aggregation of sequential file blocks before writing them to the disk. The aggregation of sequential file blocks allows multiple blocks to be allocated as a single extent (set of contiguous disk blocks) instead of separate disk blocks. By default, this feature is enabled.
For more information about the file fragmentation, see
https://en.wikipedia.org/wiki/File_system_fragmentation
The benefits of delayed block allocation are:
The following use cases might be benefited by the aforementioned capabilities of delayed block allocation.
I conducted the following tests to see the performance benefits offered by the delayed block allocation feature for the aforementioned use cases. Tests were performed with and without Delayed Block Allocation (DBA).
Test Information:
Around 590 Novell CIFS connections were used for this test. Each connection mapped the NSS volume and performed continuous write operations on different size of files. This test created around ~230GB data. The created data is read by the same number of connections after the completion of write test. Java programs were used for this test.
File sizes - 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, and 2MB
Record size – 4KB
Number of files per connection – 1000
Test Results:
Write Test – Response Time | Without DBA | With DBA | % Change w.r.t Without DBA |
Avg Open response time (ms) | 36.69 | 8.86 | -75.851 |
Avg Close response time (ms) | 29.82 | 11.58 | -61.167 |
Avg Create response time (ms) | 66.31 | 58.17 | -12.275 |
Avg Write response time (ms) | 76.09 | 28.38 | -62.702 |
Time taken for test completion (mins) | 140 | 55 | -60.714 |
Write Test - Throughput | Without DBA | With DBA | % Change w.r.t Without DBA |
Avg Write throughput (KB/sec) | 53.07 | 142.42 | 168.362 |
It can be seen that with DBA write throughput is improved by 168% and write test is taking 60% less time for the completion when compared to without DBA.
Read Test – Response Time | Without DBA | With DBA | % Change w.r.t Without DBA |
Avg Open response time (ms) | 2720.65 | 498.59 | -81.673 |
Avg Close response time (ms) | 2.71 | 2.51 | -7.38 |
Avg Read response time (ms) | 196.91 | 39.16 | -80.112 |
Time taken for test completion (mins) | 690 | 135 | -80.434 |
Read Test – Throughput | Without DBA | With DBA | % Change w.r.t Without DBA |
Avg Read throughput (KB/sec) | 20.24 | 101.79 | 402.915 |
It can be seen that with DBA read throughput is improved by 402% and read test is taking 80% less time for the completion when compared to without DBA.
The above data represents the average response time and throughput seen by the individual connection when around 590 connections are performing operations simultaneously.
Test Information:
In this test, the local backup performance is measured using the tool called TSAtest which is available as part of Open Enterprise Server. Firstly, around ~30 GB data was created for 590 Novell CIFS connections where each connection created around 50 files of 1MB size. The created data is then backed up by using the single instance of TSAtest tool to measure the backup performance
Test Results:
Backup Test | Without DBA | With DBA | % Change w.r.t Without DBA |
Total Files | 29,451 | 29,101 | |
Total Extents | 74,82,988 | 67,425 | |
Backup Throughput (MB/min) | 272.45 | 1572.13 | 477.034 |
Time taken for test completion | 103 | 18 | -82.524 |
Where extents is a bunch of contiguous blocks, which were allocated for the created files.
These test results proves that significant performance improvements are observed for both the use cases.
Please note that the above test results were observed under lab conditions and results may vary based on the test, hardware or network configuration. The number of connections, file access protocol, type of test, and number of operations also plays a crucial role in defining the test results.
The following are the hardware details for server and clients that were part of above tests:
Server Configuration:
RAM size - 16151420 kB
CPU information –
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Stepping: 9
CPU MHz: 3101.000
BogoMIPS: 6185.94
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Client Configuration:
Version – Windows 7 Enterprise SP1 32 bit
RAM size – 2GB