B. Djordjevic, V.

Timcenko LVM u Linux okruženju: ispitivanje svojstava

ISSN 1330-3651 (Print), ISSN 1848-6339 (Online)

DOI: 10.17559/TV-20131113112940

LVM IN THE LINUX ENVIRONMENT: PERFORMANCE EXAMINATION

Borislav Djordjevic, Valentina Timcenko

Original scientific paper

This paper presents a performance evaluation of LVM (Logical Volume Manager) system under the Linux operating system. The presented work includes
proposal of the mathematical modeling of file system access time with and without LVM option. A mathematical model is further validated for the case of
32bit Linux ext3 file system with kernel version 2.6, taking into consideration the comparison of a file system in two defined configurations, with and
without LVM. We have created two LVM options, with the same capacity, but different in complexity of the internal structure. The performance is
measured using the Postmark benchmarking software application that simulates workload of Internet mail server. We have defined three types of
workloads, generally dominated by relatively small objects. Test results have shown that the best option is to use direct file system realization without
applying LVM. Benchmark results are interpreted based on provided mathematical model of file system access time.

Keywords: disk model; ext3/ext2; file systems; hard disks; journaling; Linux; LVM-Logical Volume Manager

LVM u Linux okruženju: ispitivanje svojstava

Izvorni znanstveni članak

Ovaj članak predstavlja ocjenjivanje svojstava LVM (Logical Volume Manager) sustava pod Linux operativnim sustavom. Rad uključuje matematički
model vremena pristupa datotečnom sustavu sa i bez LVM opcije. Matematički model je validiran na primjeru Linux 32bit ext3, na kernel verziji 2.6, a na
bazi usporedbe svojstava datotečnog sustava konfiguriranog za dva slučaja, sa i bez LVM. Mi smo generirali dvije LVM mogućnosti, istog kapaciteta, ali
različite po složenosti unutarnje strukture. Svojstva su mjerena pomoću Postmark benchmark aplikacije koja simulira opterećenje Internet e-mail servera.
Definirali smo tri vrste opterećenja, pri čemu uglavnom dominiraju relativno mali objekti. Rezultati ispitivanja su pokazali da je najbolja opcija da se
koristi datotečni sustav bez primjene LVM. Benchmark rezultati su tumačeni na temelju matematičkog modela vrijemena pristupa datotečkom sustavu.

Ključne riječi: datotečni sustavi; ext3/ext2; journaling; Linux; LVM-Logical Volume Manager; model diska; tvrdi diskovi

1 Introduction beneficiary characteristics of LVM, such as flexible file

system resizing and snapshot options, the predominant
Linux is a modern, widespread time-sharing benefit is the feature of file system resizing, which means
operating system that supports a large number of 32-bit that logical disks can be increased or decreased without
and 64-bit journaling-based file systems such as the risk of destroying the data. However, LVM brings
ext3/ext4, ReiserFS, xfs, jfs, btrfs and zfs [1÷5]. Linux overheads due to the intensive remapping operations
supports a VFS (Virtual File System) feature, which between logical and physical block addresses
represents an object-oriented form of file system (additionally burdening the processor operation), thus
implementation. It allows to the user the identical access decreasing the disk performances.
to all files, regardless of file system that these files belong
to. LVM (Logical Volume Manager) is a novel quality 2 Related work and our solution
enhancement feature in Linux. LVM partitions have
several advantages over standard hard disk partitions. The implementation and performance research in the
LVM partitions are formatted similar to physical field of LVM is one of the most addressed topics in the
partitions, where one or more physical disks are combined area of exploring operation system architecture and
in a form of a disk group. Disk group implies that the total performances. Thus the related work can be discussed in
space for storing data is split across one or more logical three directions.
disks. Logical disks function similarly to standard One group of research papers examines comparison
partitions. They contain the same types of file systems, of different file systems in Linux environment,
such as ext3 and appropriate installation point. predominantly ext3/ext4, xfs, jfs, btrfs and zfs, whereas
For a better understanding of LVM, the physical disk these architectures are usually tested for systems relying
can be imagined as a large number of disk blocks. Several on RAID or non-RAID options [6÷14]. These papers deal
of these disks can be combined in order to make a larger with examination of file system characteristics, and
number of blocks, thus making a structure called volume mostly propose specific performance-based mathematical
disk group. The volume group can then be split into modeling, define workloads, testing methodologies, and
several smaller logical disks of random size, whereas the provide results interpretation [10, 11, 13].
new disks or partitions can also be added to logical disks. Second research topics cover the comparison of LVM
An administrator can increase or decrease the size of and non-LVM partitions, without LVM snapshot option
logical disks without destroying the data, which is not the [15]. These studies rely on the application of different
case with standard disk partitions. If the physical disks are testing methodologies, mainly based on tools such as the
in the group of disks on different RAID (Redundant Array benchmark Bonnie ++ or powerful Linux command dd
of Independent Disks) structures, the administrator can (disk dump). Based on the use of Bonnie ++ benchmark it
widen the logical disk across all the disks in RAID array. was possible to detected a low decrease in performance of
The objective of the paper is to test the influence of LVM-configured file system when compared to the native
LVM on the file system performances. Apart from all the file system. Alternatively, the application of the dd

Tehnički vjesnik 22, 5(2015), 1157-1164 1157

LVM in the Linux environment: performance examination B. Djordjevic, V. Timcenko

command in LVM file system environment has shown an 3 LVM technology

appreciable (up to 33.%) slowdown in LVM
performances. Unfortunately, majority of these papers do A LVM logical space is created in three basic steps
not consider interpretation of obtained performance [19÷27]. The first step is the selection of the physical
differences, neither provide mathematical modeling of the memory resources that will be available to LVM for use.
used system. Typically, these are standard partitions, and in LVM
Third group of studies provides results related to the terminology these physical memory resources are called
performance examination of various LVM snapshot physical space. The first step in LVM configuration
options, mostly considering mutable and immutable includes the proper initialization of these partitions so that
snapshots, time chained snapshots, and a range of they can be recognized by the LVM system. This includes
branching capabilities [16÷18]. Actually, LVM snapshots the proper adjusting of the type of partition (if a physical
provide support for backup and recovery mechanisms. partition is added) and then an application of a special
Snapshots are based on copy-on-write technology and pvcreate command.
have remarkable influence on the obtainable write Generation of one or more physical spaces initialized
performances. Most of these studies do cover successfully for the purpose of LVM represents the second step of
the snapshots behavior analysis, but rarely provide the logical LVM space creation. It implies the formation of a
examination of the difference between LVM without volume group using the command vgcreate. A volume
snapshots and non-LVM options. group can be a group of several storages that is composed
In this paper we consider the comparison of LVM of one or more physical spaces. When a LVM is active, a
and non-LVM options, and have chosen ext3 file system new physical space can be added to the volume group.
as testing environment. First, we have proposed adequate LVM is further used for the creation of one or more
mathematical model for file system for both analyzed logical spaces by using the created volume group [25, 26].
architectures, with LVM and without LVM. Then, we A classical file system can be created and used for storing
have defined proper workloads and performed a set of data in the created LVM space. For creating the logical
testing procedures. Finally, based on the obtained results space, the lvcreate command is used, which also indicates
we have provided the analysis of performance differences. the name and size of the logical space, as well as the
The testing procedure relies on the application of the name of the volume group that this logical space will be a
Postmark benchmark, and three different types of test part of.
loads. First test focuses on obtaining details related to the
performances of system working with small files. The 3.1 Workload specifications
second test explores the performances of the workload
with ultra small objects. This way we have put the system File-based workloads are designed for testing
into highly loaded and CPU difficult circumstances of procedures of file systems, and usually consist of large
performing high number of testing transactions over a number of file operations (creation, reading, writing,
large number of extremely small files. Finally we have appending, and file deletion). It comprises of large
defined third testing procedure which relies on the number of files and data transactions. Workload can be
workload with increased size of used files (compared to generated synthetically, as a result of applying benchmark
Test 1 workload). software, or as a result of working with some real data
LVM can be created using several different volumes, applications [28].
on the same disks or on different disks. In this paper, the Workload characterization is a hard problem, as
focus was on the case of LVM with one or several arbitrarily complex patterns can frequently occur. In
volumes, generated on the same physical disks, whereas particular, some authors chose to emphasize support for
there is a native ext3 volume, LVM-1, which is the spatial locality in the form of runs of requests to
simplest LVM option created from one volume, and contiguous data, and temporal locality in the form of
LVM-2, representing LVM option created from two bursty arrival patterns. Some authors [29] distinguish
volumes. Special attention was given to testing three different arrival processes:
procedures for different LVM levels under fair-play • Constant. The interarrival time between requests is
conditions, which refers to testing under the same or fixed;
similar conditions, in the same hardware environment and • Poisson. The interarrival time between requests is
under the same operating system. We have considered the independent and exponentially distributed;
same size of the file system for all tested LVM levels and • Bursty. Some of the requests arrive sufficiently close
equal amount of free space (approx. 20 GB) for testing, to each other so that their interarrival time is less than
thus we have enabled equal testing conditions. the service time.
The particular stand out and contribution of this paper
relies on the fact that all the performed tests are based on Instead of mathematical simulated workload, we have
the specifically developed workloads, testing applied synthetically generated workload in Postmark
methodologies and procedures, while the results are benchmark environment.
further analyzed taking into consideration the contributed
LVM/non-LVM mathematical model. 3.2 Mathematical model for Non-LVM file access time

In this subchapter we present the access time

estimation for non-LVM file system in general (regardless
of chosen file system) [28÷30]. Expected access time for

1158 Technical Gazette 22, 5(2015), 1157-1164

B. Djordjevic, V. Timcenko LVM u Linux okruženju: ispitivanje svojstava

non-LVM file system, for specified workload, comprises Actually, there are three dominant components,
following components: whose sum can be presented as disk service time TDST,
which is the service time for a request related to the disk
TFSA = TDO + TMO + TFL + TDFA + TJ . (1) mechanism.
These components are: (1) the seek time TSeek, which
Where TFSA (File System Access time) represents total is the amount of time needed to move the disk heads to
time that workload needs to carry out all operations; TDO the desired cylinder; (2) the rotational latency time TRL,
(Directory Operation time) represents the total time for all which stands for the time that the platter needs to rotate to
operations related to working with directories (search, the desired sector; and (3) the transfer time TM, is the time
new object creation and delete of existing objects); TMO to transfer the data from the disk medium to the next
(Metadata Operation time) represents total time needed higher level. Since these are typically independent
for performing metadata operations (metadata search variables, we can approximate the expected value of the
operations, metadata cache forming, and metadata objects disk mechanism service time to:
modifications); TFL (Free List time) presents total time
needed for performing operations with free blocks and i- TDST = TSeek + TRL + TM . (5)
node lists (file expansion/shrinking, creation of new
objects or deletion of existing objects); TDFA (Direct File The transfer time TM, is a function of two parameters,
Access time) is the time required for direct file blocks the transfer rate RT, which is the transfer rate of data
operations (read/write); TJ (Journaling time) is total time off/onto the disk and SR which represents the request size.
needed for performance of journaling operations, Function can be approximated to:
covering metadata writes to the log, and metadata log
discharge. SR
Directory operations TDO, metadata operations TMO TM = . (6)
RT
and direct file accesses TDFA are cache based accesses and
their performances directly depend on cache. Under these
conditions, the expected cache service time would be: Some variations will occur as a result of track and
cylinder switches operations and existence of different
track sizes in different disk zones. The rest of this section
SR
TCST ≈ PH ⋅ + PM ⋅ TDST . (2) describes our technique for approximating seek time and
RCT rotational latency time parameters.
Seek time. The seek time TSeek, can be approximated
Where Cache Service Time is represented by TCST, hit as the following function of dis, which is the distance
probability is denoted by PH, and represents the number calculated based on the number of cylinders to be
of hits in cache versus the total number of requests, while travelled [30]:
PM, miss probability, represents the probability of cache
miss, counted as number of misses in a cache versus the 0 dis = 0 
total number of requests. The cache transfer rate is  
marked by RCT, SR is expected request size, while disk TSeek [dis ] = a + b dis 0  dis ≤ e, (7)
service time TDST, is the total time needed to perform disk c + d ⋅ dis dis = e 
 
data transfer.
In the case of cache-miss, performances are strictly
dependent on disk characteristics TDST, and consist of where a, b, c, d and e are device-specific parameters. The
number of time based components [30]: parameters a, b, c, d are obtained with an interpolation of
the seek function which is obtained after multiple
intensive measurements of time needed for positioning of
TDST = TA + TM + TI . (3)
a specific hard drive.
Rotational latency time. If we assume that the
Where access time, TA is total access time needed for requests are randomly distributed on the sectors of the
mechanical components of disk transfer, TM is total time given cylinder using a uniform distribution, than the
needed for write/read operations from disk medium, and rotational latency time would be calculated as 1/2 of full
interface time TI is total time needed for read/write rotation time, Rrotate according to:
operations from disk cache buffer. The access time is
further defined as:
Rrotate
TRL = . (8)
TA = TCO + TSeek + TSetle + TRL . (4) 2

3.3 Mathematical model for LVM file access time

Where command overhead time, TCO, is time required
for disk commands decoding, seek time TSeek is the time LVM access time. In the case of LVM based file
needed for disk servo system positioning, settle time TSetle systems, access time analysis is more sophisticated and
stands for time required for disk head stabilization, and given in next subsection. We will start with explanation of
TRL rotational latency represents time wasted on disk LVM anatomy and LVM terminology.
rotation latency. This diagram (Fig. 1) gives an overview of the main
elements and architecture of an LVM system [19÷27].

Tehnički vjesnik 22, 5(2015), 1157-1164 1159

LVM in the Linux environment: performance examination B. Djordjevic, V. Timcenko

PV:s on partitions or DMD module maintains the information on mapping from

whole disks
the logical volume to the underlying physical volumes by
hda1 hdc1
generating and maintaining mapping table. The mappings
will differ based on the chosen type of LVM.
VG
When booting, LVM will first scan the metadata
stored within the physical volumes of the defined volume
group, with an aim to proceed with the DMD registration
diskvg of each logical volume and its corresponding mapping
table. It will end with its registration within the adequate
kernel. Thus, DMD redirects any input/output from the
LV:s
logical volume to the defined physical block device.
The LVM access time TLVM_AT is calculated
usrlv rootlv varlv according to the following equation:

TLVM_AT = TFSA + TLVM_MO . (10)

filesystems

ext2 reiserfs xfs LVM mapping overhead time TLVM_MO is function of

Figure 1 An overview of the main elements in LVM the following components: number of physical volumes,
physical PVs disk partitioning approach, size and physical
LVM system encompasses three architectural levels: positions of PVs, and volume group partitioning to logical
(1) PV (Physical Volume) which includes physical disks volumes:
or physical disk partitions (e.g. /dev/sda, /dev/sdb1); (2)
VG (Volume Group) level which combines available TLVM_MO = f ( N D , N FS , S FS , LFS ), (11)
physical volumes PVs in one single unit capable of
adding new PVs or removing existing PVs; (3) LV
(Logical Volume) level allows the user creation of logical Where ND represents the number of disks, NFS is number
partitions with common file systems as ext3, ext4, xfs, or of file systems, SFS is the size of file system, and LFS
jfs. Thus, LVM practically allows higher flexibility, represents the location of file system. LE to PE mapping
scalability and online resizing. is performed for all file system objects: files, directories,
Volume Group is the highest level abstraction used as well as for metadata objects (i-node tables, external
within the LVM. It gathers together a collection of attributes (i-node indirect block), bit maps or free block
Logical Volumes and Physical Volumes into one linked lists). Based on that concept, LVM mapping
administrative unit. overhead can be presented through the sum of two main
Logical Volume is the equivalent of a disk partition components: metadata object mapping overhead
in a non-LVM system. The LV is visible as a standard MDmapping, and file blocks mapping overhead FBmapping.
block device; as such the LV can contain a file system.
Physical Extent each PV is divided chunks of data, TLVM_MO = f ( MDmapping , FBmapping ). (12)
known as physical extents (PE), and these extents have
the same size as the logical extents for the VG. Actually, MDmapping is metadata mapping factor, and
Logical Extent each logical volume is split into FBmapping represents file block mapping factor. It is to be
chunks of data, known as logical extents (LE). The extent expected as the result of testing procedures that LVM
size is the same for all logical volumes in the VG. mapping overhead will bring some decrease in file system
LE to PE mapping. The administrator can choose performances.
between several general strategies for mapping logical The Eqs. (1) to (12) are applicable to any
extents onto physical extents, like following 2: journaling/LVM Linux based file systems
- Linear mapping will assign a range of PE's to an area (ext3/ext4/jfs/xfs/btrfs), but it is necessary to take into
of an LV in order consideration that these file systems differ in achievable
- Striped mapping will interleave the chunks of the quality of time metrics defined in equations.
logical extents across a number of physical volumes.
3.4 Hypotheses on the expected LVM performances
LVM mapping between logical and physical extents
(LE to PE mapping) is the basic factor that will have an The preliminary hypotheses based on the proposed
impact to the LVM and Non-LVM file system mathematical model are:
performance differences. The Device Mapper Driver has a H1: It is expected that the non-LVM over performs LVM
functionality of providing LVM mapping of the logical H2: H1 relies in LVM mapping overhead, Eq. (10)
volumes to the disk physical blocks. For each logical H3: Mapping overhead depends on the complexity of the
volume the DMD keeps record of the device mapping LVM implementation (number/type of physical volumes)
table based on which it maps the request to specific H4: Mapping overhead depends on the nature of the
physical disk block. workloads (read/write/random/sequential components).
DMD provides different forms of mapping: Linear, It is assumed that the mapping overhead depends on
Striped, Snapshot, and Snapshot-Origin. Each mapping the applied file system (ext3, ext4, xfs, jfs, btrfs), but it is
form implies the redirection of the IP requests to a out of scope of this paper and will be left for future work.
specific underlying physical device. Additionally, the

1160 Technical Gazette 22, 5(2015), 1157-1164

B. Djordjevic, V. Timcenko LVM u Linux okruženju: ispitivanje svojstava

Although on the basis of Eq. (10), we expect that LVM Table 1 FS layout without LVM
slows the performances, we must be careful. In the area of File system Size description
the computer techniques many things are not obvious as LogVol00 58GB root FS
they can look like. For example, let's take the journaling LogVol01 1GB Swap
dev/sda3 20GB testing FS
technique into consideration. Many potential users will
think that journaling techniques with their additional log
writes would slow down the performances, but experience In the second case, LVM is made of one physical
shows that this is not always the case. Many papers that volume (/dev/sda3 as a physical volume of 20 GB and
can be found as open literature, including some of our logical group LogVol02 of 20GB in ext3 format), as
own researches [9], show that journaling can also provided in Tab. 2.
accelerate the performance. Thus, from these
Table 2 FS layout with an LVM composed of one PV, LVM-1
experimental researches we could learn that nothing can File system Size Description
be taken as obvious, but it has to be proven. LogVol00 58GB root FS
A very similar situation can occur in the case of LogVol01 1GB Swap
LVM/Non-LVM environments. We have tried to very dev/sda3 20GB physical volume
precisely examine: (1) whether LVM slows down or even LogVol02 20GB testing FS
improves the performances; (2) what are the
circumstances when it slows down; and (3) what are the In the third case, LVM is composed of two physical
parameters that this trend depends on. volumes (/dev/sda3 and /dev/sda4 as physical volumes of
10GB and logical group LogVol02 of 20 GB in ext3
4 Mathematical model validation and result analysis format). Details are given in Tab. 3.
For second and third case, an empty ext3 file system
The validation of the proposed mathematical model, is created in a logical group LogVol02. LogVol02 is
as well as the confirmation of stated hypotheses is specially created for the purpose of testing, and it can be
achieved through a synthetic benchmarking for 32bit ext3, accessed through the path /dev/mapper/VolGroup00-
which is one of the most stable, fast and widely accepted LogVol02. The file system used for testing is of exactly
32bit journaling file systems, with a long history of bug- the same size for all the tests and tested LVM levels.
fixes and performance improvements. We emphasize that
this file system is still relevant, as there is a large number Table 3 FS layout with an LVM composed of two PVs, LVM-2
of ext3 file system users. Just to mention that ext3 file File system Size Description
system is often present in Linux Xen virtualization, which LogVol00 58 GB Root FS
shows superior results in comparison to competitors LogVol01 1 GB Swap
(KVM, VMware, Hyper-V). However, such a Linux Xen- dev/sda3 10 GB physical volume
based virtualization is typical for some older Linux dev/sda4 10 GB physical volume
distributions, where ext3 was the default file system (FS). LogVol02 20 GB testing FS
Although the newer ext4 file system would be an
interesting topic for LVM examination, there is also a 4.2 Testing procedures and analysis
long list of possible FS candidates for creating LVM
volumes: 32bit ext2/ext3, and different 64bit file systems For the purpose of this paper we have used PostMark
(ext4, xfs, jfs, btrfs). As we have thoroughly examined the [31], software that simulates loading an Internet Mail
LVM vs. non-LVM for ext3, we believe that it would be server. PostMark creates a large initial pool of randomly
interesting for further work to proceed with same testing generated files in any place in the file system. This pool is
procedure for the mentioned 64bit candidates, and we further used for creating, reading, writing and file
expect that the results would confirm our hypotheses, deleting, and the time required for these operations is
especially H1 and H3 (that LVM introduces performance determined. The sequence of these operations is random
decrease when compared to native file system, and that therefore the simulation credibility is guaranteed. The
these decelerations are greatly affected by the complexity number of files, their size range and the number of
of the LVM configuration). transactions are fully configurable. In order to eliminate
the cache effect it is recommendable to create an initial
4.1 Test configuration pool with as many files as possible (at least 10,000) and
perform as many transactions as possible.
For testing purposes, we have chosen disks from the We have presented the results of three different test
WDC WD800BD-22MR-80GB series (80 GB, average procedures. Test 1 is based on testing of small files (file
seek time 8,9 ms, rotational speed 7200 rpm, maximum sizes between 1KB and 100KB) and this test results will
disk buffer throughput 1,5 Gb/sec) and Red Hat Linux be a reference when comparing other test results. Test 2
version Fedora 10 with kernel version 2.6.27. For the considers drastically smaller files (sizes between 1byte
purpose of testing, the file system is organized in the form and 1KB) and appreciably increased number of generated
of logical partitions, where the last part of disk (20GB) is files, which will generate high number of metadata
created in three different ways and used for testing. operations with ultra-small objects. Test 3 considers
In the first case, direct file system realization was slightly increased size of generated files when comparing
created without the use of LVM (/dev/sda3 of 20GB in to Test 1, which implies higher dataflow in workload.
ext3 format), as it is provided in Tab. 1.

Tehnički vjesnik 22, 5(2015), 1157-1164 1161

LVM in the Linux environment: performance examination B. Djordjevic, V. Timcenko

4.2.1 Postmark Test 1 Table 5 Results for Postmark Test 2

KB/s ext3 LVM-1 LVM-2
Files used for the purpose of performing this testing read 149,82 81,96 23,03
procedure are relatively small, ranging from 1KB to 100 write 345,15 188,82 53,06
KB. The results are given in Tab. 4 and on Fig. 2. In this
test of small files, direct file system realization without
the use of LVM shows superior performances in
comparison to the two tested LVM configurations. Direct
file system realization without the use of LVM is about 63
% faster than an LVM-1 realization with one physical
volume, and it is 2,5 times faster than an LVM-2
realization with two physical volumes. LVM-1 realization
with one physical volume is approximately 50 % faster
than an LVM-2 realization with two physical volumes.
The workload for this test is characterized with lower
number of files (4000), moderate number of create/delete Figure 3 PostMark Test 2 results
operations, file size of 1 k ÷ 100 k, and solid amount of
reads/writes (1.6GB-r/1.8GB-w). Having into The workload for this test is characterized with high
consideration the equation (1), it can be expected that number of files (30.000), high number of create/delete
component TDFA will be dominant. operations, ultra-small file sizes (1byte-1K), and low
amount of reads/writes (13.61MB-r/31.35MB-w). Having
Table 4 Results for Postmark Test 1 into consideration Eq. (1), it can be expected that
MB/s ext3 LVM-1 LVM-2 components sum TDO + TMO will be dominant. Taking into
Read 2,99 1,83 1,21 consideration Eq. (11), in this specific case, as there is
Write 3,49 2,14 1,42 large number of metadata operations (noticeable larger
than in Test 1), metadata object mapping overhead
component has dominant influence to the remarkable
LVM performance decrease. In the case of LVM-2 it is
evident that the amount of metadata mappings was
significantly greater than in the case LVM-1, resulting in
significant decrease of LVM-2 performances.

4.2.3 Postmark Test 3

This is a very intensive test. Files used for this testing

procedure are relatively large (1KB-300KB). Results are
Figure 2 PostMark Test 1 results given in Tab. 6 and on Fig. 4.
In the test of larger files, direct file system realization
Starting from Eq. (11), we will consider that this test without the use of an LVM also shows superior
assumes both kinds of mapping (metadata object mapping performance when comparing to LVM configurations.
overhead and file blocks mapping overhead), and that
both of them have an impact to the decrease of LVM Table 6 Results for Postmark Test 3
KB/s ext3 LVM-1 LVM-2
performances. In Test 1, block remapping overhead has a
read 2,8 2,4 0,91
dominant influence on the decrease of LVM options
write 3,25 2,79 1,03
performance when comparing to native ext3.

4.2.2 Postmark Test 2

This is also a very intensive test procedure as it

involves a large number of very small files, ranging from
1bytes to 1KB. The test generates a large number of
metadata I/O requests. The results are given in Tab. 5 and
on Fig. 3. In this test of ultra-small files, direct file system
realization without the use of LVM shows superior
performance in comparison to the two tested LVM
configurations. Direct file system realization without the
use of LVM is approximately 80 % faster than an LVM-1 Figure 4 PostMark Test 3 results
realization with one physical volume and it is 6,5 times
faster than a LVM-2 realization with two physical Native file system realization without the use of LVM
volumes. LVM-1 realization with one physical volume is is approximately 16 % faster than an LVM realization
significantly faster (3,5 times) than an LVM realization with one physical volume, and it is 3 times faster than an
with two physical volumes. LVM realization with 2 physical volumes.

1162 Technical Gazette 22, 5(2015), 1157-1164

B. Djordjevic, V. Timcenko LVM u Linux okruženju: ispitivanje svojstava

LVM realization with one physical volume is H3. LVM shows greater loading and weaker
significantly faster (2,5 times) than an LVM realization performance if realized in a more complex way,
with 2 physical volumes. meaning that if an LVM is created from several
The workload for this test is characterized with lower different volumes it is possible to achieve
number of files (4000), moderate number of create/delete significantly lower performances. It is also expected
operations, file size of 100 k ÷ 300 k, and solid amount of that the performances will further decrease if a LVM
reads/writes (4.6GB-r/5.4GB-w). Having into is created from volumes located on different physical
consideration the Eq. (1), it can be expected that TDFA disks, which was not directly tested in this paper and
component will be dominant. Again, it is worth will be discussed in some further work.
considering Eq. (11), and notice that in Test 3, as the size • The performance decrease depends directly on the
of tested files has increased in comparison to the files workload, number of the required disk operations,
generated in Test 1, there is appreciably higher number of metadata operations and number of direct file block
file blocks, while the number of metadata operations is operations (confirmation of the H4 hypothesis).
approximately the same as in Test 1. Therefore, the file • The main cause of the noticed performance decline is
blocks mapping overhead in LVM has dominant role to the feature of remapping. The remapping in the case
the very significant decreasing of LVM performances. of the LVM is performed by the DMD. This
The more complex file block remapping procedure for procedure is weakly compensated by the remapping
increased number of file blocks in the case of LVM-2 has caching. The obtained results confirm the H2
caused appreciable decrease in performance when hypothesis.
compared to LVM-1, and this difference is more intense
than the one detected in Test 1. It is pointed out to the users that the complex LVM
implementation should be an interim solution, while final
4.3 General remarks for all three Postmark tests one should be the LVM with the simplest possible design
or non-LVM at all.
In this paper, we have presented the results of Our LVM test methodology fits well when dealing
PostMark tests for (1) basic file system without the use of with QoS (Quality of Service) issues related to
LVM, and (2) two LVM realizations with one or two virtualization and cloud computing, as the concept of
physical volumes. Our goal was to consider different LVM is often seen as file system options for Linux based
working circumstances, by first examining a workload of host and guest operating systems. Therefore, LVM could
small files, and then in the second test substantially have a large performance impact on virtual environments,
increased the number of metadata operations, while in the different cloud computing environments, as well as to
third experiment we have considerably increased the data centers. Many Linux users or administrator will
number of blocks for file transfer. linearly proceed with expand their storage space of
Taking into consideration all the obtained results, as existing workstations/servers by simply adding new hard
the confirmation of the preliminary hypotheses H1 ÷ H4, drives, thus obtaining the needed expansion in rapid and
it can be observed that the native non-LVM realization is non-destructive way. Their existing LVM volumes will be
solidly better than LVM, while LVM with one or two expanded with new disks and partitions without data loss,
physical volumes shows significantly lower performance which is a relatively quick procedure and is in compliance
in 2 out of 3 tests: in the test with ultra-small files and in with the primary purpose of LVM (easy storage
the test with somewhat larger files, in each case with huge expansion/shrinking). But, in that way there is a risk of
number of disk metadata or direct file access operations. creating relatively complex LVM designs. In this paper, it
is proved that the complex LVM can suffer from
5 Conclusion significant performance decline, and showed that this
quick and easy solution based on the LVM volume
The obtained experimental results fully confirm the spreading should be just an interim solution, not the final
set of preliminary hypotheses and validate the proposed one. The suggested solution is based on first proceeding
mathematical model. The beneficial characteristics of with long-term full backup operation, following with
LVM should be highly appreciated, as LVM provides the reconfiguration of the used LVM to the simplest possible
flexible widening of file systems, with new partitions on design. Finally, after these steps it is recommendable to
the same or different disks, during which there is no data run a full restore procedure. Alternatively, in the presence
loss. But it has to be taken care of the fact that LVM of the performance-critical applications, it is
represents a new layer in the virtual file system hierarchy, recommendable to proceed with the complete replacement
which creates overheads for processing, thus has a of the LVM with available native file system.
negative impact on performances. The compensation of Future work will encompass performance analysis of
the LVM mapping overhead is partially performed by more sophisticated LVM types, with focus on LVM case
file-caching features, although it is always present in when implementing multiple partitions and multiple
some form. This is confirmed by the provided test results. physical disks. It will cover LVM performances on the
In general we can conclude that: 64bit file systems as an enhancement to the results
• LVM provides reduced level of performances when presented in this paper, as well as LVM on the RAID,
compared to non-LVM file system, which confirms LVM with activated snapshots options and LVM in the
H1. virtual and cloud computing environment.
• Decrease in performances highly depends on the
complexity of LVM configuration, thus confirming

Tehnički vjesnik 22, 5(2015), 1157-1164 1163

LVM in the Linux environment: performance examination B. Djordjevic, V. Timcenko

Acknowledgements [19] Radhakrishnan, P. Stateful-Swapping in Emulab network

testbed (Master’s Thesis). // The University of Utah, 2008.
The presented work has been funded by the Serbian [20] The original version of LVM. LVM Resource Page. URL :
Ministry of Education, Science and Technological https://www.sourceware.org/lvm
[21] Danen, V. Set up Logical Volume Manager in Linux. //
Development (TR32037, TR43002 and TR 32025). Techrepublic online, Mar 09 2007. URL:
http://www.techrepublic.com/article/set-up-logical-volume-
6 References manager-in-linux/
[22] Toft, G. Using Logical Volume Management. // Linux
[1] Seltzer, M.; Ganger, G.; McKusick, M.; Smith, K.; Soules Journal. URL: http://www.linuxjournal.com/article/5957.
C.; Stein C. Journaling versus Soft Updates: Asynchronous (23.09.2002.)
Meta-data Protection in File Systems. // Proceedings of the [23] Scalzo, B. Optimizing Oracle 10g on Linux: Non-RAC
USENIX Conference / San Diego, 2000, pp. 71-84. ASM vs. LVM. // Linux Journal (31.08.2005.). URL:
[2] Silberschatz, A.; Galvin, P. Operating System Concepts. http://www.linuxjournal.com/article/8539
Addison-Wesley, 2007. [24] Bulling, R. Recovery of RAID and LVM2 Volumes. //
[3] Avantika, M..; Cao, M.; Bhattacharya, S.; Dilger, A.; Linux Journal URL: http://www.linuxjournal.com/
Tomas, A.; Vivier, L. et al. The new ext4 filesystem: article/8874 (28.04.2006).
current status and future plans. // Proceedings of the Linux [25] Lewis, A. J. LVM HOWTO // The Linux Documentation
Symposium, vol. 2 / Ottawa, Canada, 2007, pp. 21-34. Project, 2006.
[4] Tweedie, S. EXT3, Journaling Filesystem. 2000, 7. [26] Pillai, S. The Advanced Guide to LVM-Logical Volume
[5] Hagen, B. Exploring the ext3 Filesystem. Linux Planet, Management on Linux: PART1. // Slashroot.in Magazine,
2002, 4. URL: http://www.linuxplanet.com/linuxplanet/ 2013
[6] reports/4136/1 (5.04.2002). [27] Red Hat, Red Hat Ent. Linux6, Logical Volume Manager
[7] Machado, A. LVM, RAID, XFS and EXT3 file systems Administration LVM Administrator Guide, Ed.1, 2013.
tuning for small files massive heavy load concurrent [28] Red Hat Linux: What is Logical Volume Manager or
parallel I/O on Debian. // Quarta-Feira, 4 de Julho de 2012. LVM? // Technology Magazine (6.08.2013.).
[8] ZFS vs. EXT4 on Linux Multi-Disk RAID Benchmarks. [29] Smith, K. A. Workload-Specific File System Benchmarks.
Phoronix, 25 April 2013, The Web version 4(2013) PhD thesis. // Harvard University Cambridge,
[9] Phromchana V.; Napuairoj N.; Piromsopa K. Performance Massachusetts, 2001.
Evaluation of ZFS and LVM (with ext4) for Scalable [30] Shriver, E.; Merchanty, A.; Wilkesy, J. An analytic
Storage System. // 8th Int. Joint Conf. On Computer Science behaviour model for disk drives with readahead caches and
and Software Engineering (JCSSE) / Mahidol University, request reordering. // Proceedings of the ACM
NakhonPathom, Thailand, 2011, pp. 250-253. DOI: SIGMETRICS joint Int. conference on Measurement and
10.1109/jcsse.2011.5930130 modelling of computer systems / 26, 1(1998), pp. 182-191.
[10] Djordjevic, B.; Timcenko, V. Ext4 file system in Linux [31] Akpinar, O. Performance Analysis of the Disk Subsystem.
Environment: Features and Performance Analysis. // Rutgers // The State University of New Jersey, New
International Journal of Computers. 6, 1(2012), pp. 37-45. Brunswick, 2006.
[11] Piernas, J.; Cortes, T.; García, J. M. Dual FS: a new [32] Katcher, J. PostMark: A New File System Benchmark. //
journaling file system without meta-data duplication. // Technical Report TR3022 / Network Appliance Inc (1997).
Proc. of int. conference on Supercomputing (ICS '02).
ACM, New York, 2002, pp. 137-146. DOI:
10.1145/514191.514213 Authors’ addresses
[12] Lee, E.; Yoo, S.; Jang, J-E.; Bahn, H. Shortcut-JFS: A write
efficient journaling file system for phase change memory. // Borislav Djordjevic, PhD, Associate Professor
Symposion on Mass Storage Systems (MSST) 2012, pp. 1- University of Belgrade,
6. Institute Mihailo Pupin, Computer Systems department
Volgina 15, 11060 Belgrade, Serbia
[13] Vickovic, L.; Mudnic, E.; Gotovac, S. Parity information
E-mail: [email protected]
placement in the disk array model. // COMPEL - The Int. J.
for Computation and Mathematics in Electrical and Valentina Timcenko, Magister, Associate researcher
Electronic Engineering. 28, 6 (2009), pp. 1428-1441. DOI: University of Belgrade,
10.1108/03321640910991994 Institute Mihailo Pupin, Telecommunications department
[14] Sehgal, P.; Tarasov, V.; Zadok, E. Evaluating performance Volgina 15, 11060 Belgrade, Serbia
and energy in file system server workloads. // Proc. 8th E-mail: [email protected]
USENIX conference on File and storage technologies
(FAST'10). / USENIX Association, Berkeley, CA, USA,
2010, pp. 19-19.
[15] Dagenais, M. R. Disks, partitions, volumes and RAID
performance with the Linux operating system. // Computing
Research Repository, 2005.
[16] Smorul, M. LVM vs normal disk partitioning speed testing
with Bonnie ++. URL: http://www.umiacs.umd.edu/
~toaster/lvm-testing/
[17] Nayak, P.; Ricci, R. Detailed study on Linux Logical
Volume Manager. // Flux Research Group University of
Utah, August 1, 2013.
[18] Shah, B. Disk Performance of Copy-On-Write Snapshot
Logical Volumes (Master’s Thesis). // The University of
British Columbia, 2006.

1164 Technical Gazette 22, 5(2015), 1157-1164