1. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
TECHNOLOGY (IJCET)
ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 5, Issue 1, January (2014), pp. 46-51
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2013): 6.1302 (Calculated by GISI)
www.jifactor.com
IJCET
©IAEME
A GENERIC PERFORMANCE EVALUATION MODEL FOR THE FILE
SYSTEMS
Mr. Naveenkumar Jayakumar1,
Mr. Farid Zaeimfar2,
Mrs. Manjusha Joshi3,
Dr. Shashank.D.Joshi4
1,2,3,4
(Department of Computer Engineering, College of Engineering, Bharati Vidyapeeth Deemed
University, Pune, India)
ABSTRACT
The development in technology has led a boom in the data being consumed and processed.
The data size has been a major factor which actually need to be monitored in a way of how it is being
accessed and processed in order to have high complex performance systems. The file systems and
database are the core focus area of how the data is stored and retrieved whenever the data is required.
This era belongs to the high performance computing. The file systems also needs to be that much
capable of managing the data and responding to the requests. This paper will provide with a novel
approach of evaluating the file systems and the computing systems for engineering better systems
and tuning systems by reviewing the current existing file systems. There is great necessitate for
performance model of current systems in order to cope up with huge number of requests and
exploding data. This paper put forth, that any architect of high performance computing systems,
clustered systems and in advanced cases the cloud systems should consider these techniques which
are proposed in this paper.
Keywords: Performance Evaluation Techniques, File Systems, Cluster File System Performance
Model.
I. INTRODUCTION
Since there exists various types of file systems in the current infrastructure like local file
systems and global file systems which will include clustered and distributed files systems as well.
They behave and function differently from others. These existing file system performance needs to
be enhanced in order to improve the performance of clustered system, distributed systems. Thus, it is
required to develop a way of understanding the performance of file systems, how they behave in the
environment and how can be it tuned in order to feel performance improvement.
46

2. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
How in a computing environment, a result needs to be stored and how the input to the
compute is supplied to computation process is decided by the file systems. So a file system is the
controller for storing and retrieving the data. Since there are many kinds of the file systems, they all
have different structure and different logics. A file system consist of multiple interface and
components. The most important component is the metadata. Metadata is data about data. While
analyzing the file system, it is necessary to understand the metadata management and plays a role in
analyzing the overall performance of the file system.
These days there are many proliferation of file systems in a distributed computing
environment, like GFS, NFS etc. which mostly relate to handle hugely large datasets and providing
high availability and high speed of access. Having a performance benchmark performed for the file
systems and storage systems will be difficult of the contributing factors of complex systems
development like variations an storage architectures and the way they communicate, variations in the
file systems structures and the way they behave in the environment, operating system difference,
what kind of workload is applied to the system, synchronous and asynchronous operating being
performed and caches deployed in the systems.
The file systems resides in the file server. Understanding the basic operations or internals
behind the file systems. A request is received from the client, this request is processed by the file
server and the request data is forwarded to metadata for understanding what data need to be written
where or from where the data needs to be read. With metadata help, the file system writes the data or
reads the data from the physical drive. After the operations performed, the file system is responses
and acknowledges to the client. In the traditional file systems, all the components of file system is
handled by the file server and the I/O intensive as well as the data intensive operations are also
handled by the same file server. But in order to improve the performance and minimizing the load on
the server, they distributed the metadata and file system components on different file servers, thereby
increasing the inter communications between the nodes.
In terms of file system metadata, these are monitored and executed by dedicated servers in
the recent architectures of storage systems. These metadata are represented as the objects so we have
the objects managing servers. The client operations are handled by the different servers like handling
the I/O bound and CPU bound operations. The figure 1 shows the architecture of file system
deployed in distributed environment.
Figure 1: File system in distributed Environment
47

3. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
II. EVALUATION REVIEW
The evaluation of the file system can be varied with techniques deployed like benchmarking,
profiling, ad-hoc efficient techniques, direct and indirect techniques. This paper will be focus on the
first two techniques rather than all and also an approach which will state the required steps to be
considered in order evaluate the performance of the file systems.
The benchmark process is the way or style of evaluating the performance. The process which
is executed to understand and identify the performance of the components as well as the whole
system. In a benchmarking process, it is not suitable to have a single benchmark because there are
various components and various types of the components which behave in a varied manner that can’t
brought under the one benchmark evaluation. So that’s why the benchmark evaluation becomes a
challenging task to execute. The benchmarking can be performed in various ways like micro
benchmarking, macro benchmarking and replays. The micro benchmarking helps in identifying the
response time, latency and processor utilization etc. of a system when the operations of the file
system are executed. These are used in order to get insight into the operations performed and helps in
understanding the macro benchmarks. It can also depict the worst case, average case and best cases
of the operations behavior by isolating the performance of that particular component and operations.
In case of macro benchmarking, the files system is executed with pre-determined workload.
The macro benchmarking, focuses on identifying the work load to be used for testing. The
application is executed at the client side and the workload is pumped to the file system and it is
observed that how the file system behaves to the varying the workload.
Considering, the replays, the traces i.e. the logs are measures and recorded at each
components and interface in order to verify at later stage. These are responsible for understanding the
behavior of the system components and the software stacks. This replaying traces is used for
advancement of the file systems, user behavior analysis, security, auditing and testing etc.
Profiling is the evaluation methodology, where you can group the software’s based upon their
behavior or the file systems can be analyzed on the overall behavior of it in a given environment.
Again, the profiling of same software will vary with respect to environment in which it is deployed
and work applied to it.
III. EVALUATION APPROACH
In this paper, the performance evaluation approach has been proposed in order to clearly
understand the tuning components of the system as well the logical units of the file system which can
be enhanced or modified in order to improve the performance. The steps of the approach are:
Step 1 Consider the file system and decide upon the where it is going to be deployed or already is
implemented and understand the scenario of work.
Step 2 Understand the applications run in the scenario. What kind of workload is being generated by
the applications and is pumped to file system nodes. The workload should consider following
parameters like I/O size, Access Pattern – random or sequential, Operation type, Operation
percentage, Block size, time for which application run etc. these parameters may be dynamic in
nature when the real time application is deployed or we can use the synthetic workload generator and
use the custom application to generate the workload and specifying these fixed parameters. The
workload can be varied by varying the parameters and applying this to the same system.
48

4. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
Step 3 Setting up the tested. The test bed should consist of all the hardware structures required and
set up the network in resemblances to the real time network and hardware.
Step 4 Configuring the logical environment with the hardware structures. If the test is for single node
then the application as well as the file system will reside in the same node or in a distributed
environment the application in one node, file system in one node and meta data in one node and
these all nodes should be configured in such a way they all interact with each other, which will
actually explain the architecture of the system. The bandwidth available, the number of disks, raid
configurations, application configuration etc. can be fixed in this phase.
Step 5 Metrics to be measured. Fix the metrics and parameters which are essential to be measured
when the test is run. The metrics should be differentiated between the whole system and file system.
For the file system, it is necessary to understand the metrics like latency for each operations, the time
taken by the Meta data to resolve the dependencies and the retrieving the data or storing the data to
file or block. The metrics should also include, the time spent in interacting with other nodes. Cache
effects should also be measured and a relation should be established between these metrics and their
dependencies with factors discussed in above steps.
Step 6 Execution of the tests. The more time for execution, the better results for performance. The
more time the test executes, it is feasible to understand how well the application can be executed and
how well the file system behaves to it.
Step 7 as show in the model below, the tracer logs each and every possible operations and workload
performed by the file system and stores it in a disks. The data is huge, using this data and the metrics
defined in the above steps, it is possible to generate a statistical performance model which in turn is
used for tuning and analyzing the performance and conclude with how to improve the performance.
The model works in the fashion where all the benchmarking techniques and profiling is
clubbed and formed a hybrid model. This is a parallel model where the operations can be measured
as well as the workload variation impact can also be measured. There is a component which is called
as tracer which accumulates all the logs and stores on the disk and is retrieved at the time of
performance modelling or generating the statistical model.
The figure 2 represents the approach at the each layer of a distributed systems. The file
system as well as the component of metrics values are recorded in order to understand the
performance. Some of the metrics for the system oriented are IOPS, FLOPS, Response time,
Throughput etc. In case of the file system it can be I/O size, Block size, Requests per seconds, Meta
data operations per seconds calculated through request/ per seconds, time spent by for completing
one file operations etc. these metrics are calculated by the tool which are being used and stored to the
disks.
The dotted boxes in the figure 2 represents the metrics and component values which has been
accumulated by the tracer and it saves it to the disks. In case the files are object oriented then, the
object Id and mapping of object Id to the directory, metadata and file will be considered here. In case
of the object oriented, the metadata management will be represented in objects and the file
management will represented in objects and the virtualized disk will also be an object. The
programming model for executing this architecture is different and the interfaces will also be
differently implemented, but the tracer can be implemented in any kind of architecture in order to
analyze the performance through quantitative measure of metrics and individual components.
49

5. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
Figure 2: Propose approach of analyzing Performance
50

6. International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
IV. CONCLUSION
The aim of this paper was to provide insight into the file system performance evaluations
through reviewing the existing techniques and proposing the new file system evaluation based on the
other techniques. The paper concludes performance evaluation to be made more precise and more
depth through analyzing the performance at each component of the system and logical units of file
systems. The tracer has been proposed here which will accumulate the metrics and logs provided by
the whole test execution and by understanding these values a statistical model can be derived which
can be further used for tuning the systems or architecting new file systems and engineering new
distributed systems.
V. REFERENCES
[1]
Robert C. Gray. The 1999 Outlook for Storage Area Networks. Presented at Getting
Connected ’99 hosted by the Storage Network Industry Association Board. May 19 - 20,
1999.
[2] Brad Kline, Pete Lawthers. CVFS: A Distributed File System Architecture for the Film and
Video Industry, a MountainGate White Paper, June, 1999. MountainGate Imaging Systems,
Inc. and Prestant Technology, Inc.,
[3] Kenneth Preslan et al., Implementing Journaling in a Linux Shared Disk File System. In The
Eighth Goddard Conference on Mass Storage Systems and Technologies in cooperation with
the Seventeenth IEEE Symposium on Mass Storage Systems, College Park, Maryland, March
2000, (these proceedings)
[4] Alessandro Rubini. Linux Device Drivers. O’Reilly & Associates, 1998.
[5] E. Anderson, M. Kallahalla, M. Uysal, and R. Swaminathan. Buttress: A toolkit for flexible
and high fidelity I/O benchmarking. In Proceedings of the Third USENIX Conference on File
and Storage Technologies (FAST 2004), pages 45–58, San Francisco, CA, March/April 2004.
USENIX Association
[6] Nathwani Namrata, “Network Attached Storage Different from Traditional File Servers &
Implementation of Windows Based Nas”, International Journal of Computer Engineering &
Technology (IJCET), Volume 4, Issue 3, 2013, pp. 539 - 549, ISSN Print: 0976 – 6367,
ISSN Online: 0976 – 6375.
[7] G.Kasi Reddy and Dr.D.Sravan Kumar, “Study on Models of Performance Evaluation of
Software Architectures”, International Journal of Computer Engineering & Technology
(IJCET), Volume 3, Issue 2, 2012, pp. 378 - 388, ISSN Print: 0976 – 6367, ISSN Online:
0976 – 6375.
[8] Don Capps. IOzonefilesystem benchmark. www.iozone.org/, July 2008.
[9] P. Shivam, V. Marupadi, J. Chase, T. Subramaniam, and S. Babu. Cutting corners:
Workbench automation for server benchmarking. In Proceedings of the Annual USENIX
Technical Conference, pages 241–254, Boston, MA, June 2008. USENIX Association.
[10] C. P. Wright, N. Joukov, D. Kulkarni, Y. Miretskiy, and E. Zadok. Auto-pilot: A platform for
system software benchmarking. In Proceedings of the Annual USENIX Technical
Conference, FREENIX Track, pages 175–187, Anaheim, CA, April 2005. USENIX
Association.
51