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,
1,2,3,4

Mr. Farid Zaeimfar2,

Mrs. Manjusha Joshi3,

Dr. Shashank.D.Joshi4 (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

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

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 cant brought under the one benchmark evaluation. So thats 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 softwares 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

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

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

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 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. OReilly & 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 4558, 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 241254, 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 175187, Anaheim, CA, April 2005. USENIX Association. [1]

51