LP2PFS: Um Cliente VFS Linux Para O Sistema LP2P

Total Page:16

File Type:pdf, Size:1020Kb

LP2PFS: Um Cliente VFS Linux Para O Sistema LP2P LP2PFS: Um Cliente VFS Linux para o Sistema LP2P por Daniel Stefani Marcon UNIVERSIDADE DO VALE DO RIO DOS SINOS DANIEL STEFANI MARCON LP2PFS: Um Cliente VFS Linux para o Sistema LP2P Monografia apresentada como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação Prof. Dr. Rafael Bohrer Ávila Orientador São Leopoldo, Dezembro de 2010 “Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity. — Charles Mingus DEDICATÓRIA Dedico este trabalho a minha dinda-mãe Darcila, que sempre me apoiou e me ajudou em todos os momentos da minha vida. AGRADECIMENTOS Agradeço, em primeiro lugar, a Deus, por ter me proporcionado finalizar este trabalho. Agradeço a minha dinda-mãe Darcila e ao meu dindo Fausto pela ajuda em todos os momentos durante esse trabalho, que me apoiaram durante toda a minha vida para mim chegar até aqui. Agradeço ao meu orientador Rafael, por toda a orientação durante o trabalho, pelos conselhos sobre a melhor forma de implementar o sistema de arquivos, sobre o que escrever e como apresentar o projeto nessa monografia e pelas revisões desse texto. Agradeço a todos os meus amigos que me ajudaram durante esse trabalho, direta ou indiretamente. SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS . .7 LISTA DE FIGURAS . .9 LISTA DE LISTAGENS . 11 LISTA DE TABELAS . 12 RESUMO . 13 ABSTRACT . 14 1 INTRODUÇÃO . 15 2 REFERENCIAL TEÓRICO . 19 2.1 Sistemas Centralizados ............................ 19 2.1.1 Network File System - NFS ........................ 19 2.1.2 Samba ................................... 22 2.2 Sistemas Distribuídos ............................. 24 2.2.1 Coda .................................... 24 2.2.2 Serverless Network File System - xFS ................... 26 2.3 Sistemas Peer-to-Peer ............................ 28 2.3.1 Gnutella .................................. 29 2.3.2 Freenet ................................... 31 2.3.3 Ivy ..................................... 33 2.3.4 BitTorrent ................................. 35 2.4 Síntese .................................... 37 3 LOCAL PEER-TO-PEER PROTOCOL . 40 3.1 Arquitetura .................................. 41 3.2 Mensagens de Comunicação Interna ..................... 44 3.3 Módulos Externos .............................. 46 4 LP2P FILE SYSTEM . 48 4.1 Implementação ................................ 48 4.1.1 Virtual File System ............................. 49 4.1.1.1 Mapeamento dos Metadados dos Arquivos ............... 55 4.1.2 Page Cache ................................ 55 4.1.2.1 Mapeamento dos Dados dos Arquivos ................. 57 4.2 Otimizações .................................. 58 4.3 Comunicação com o LP2P .......................... 60 4.4 Notificação de Eventos ............................ 61 4.5 Arquivo no Sistema Procfs .......................... 62 4.6 Opções de Montagem ............................ 63 5 VALIDAÇÃO E RESULTADOS EXPERIMENTAIS . 64 5.1 Versões do Kernel .............................. 64 5.2 Disponibilização dos Arquivos ........................ 65 5.3 Testes no Sistema LP2P ........................... 66 6 CONCLUSÃO . 73 REFERÊNCIAS . 75 LISTA DE ABREVIATURAS E SIGLAS API Application Programming Interface CA-NFS Congestion Aware Network File System CIFS Common Internet File System CHK Content-hash Key DNS Domain Name System DNS-SD Domain Name System Based Service Discovery FTP File Transfer Protocol GCC GNU Compiler Collection GNU GNU’s Not Unix! HTTP Hypertext Transfer Protocol KSK Keyword-signed Key LAN Local Area Network LFS Log-structured File Systems LRU Least Recently Used mDNS Multicast Domain Name System NFS Network File System P2P Peer-to-Peer pNFS Parallel Network File System POSIX Portable Operating System Interface RAID Redundant Arrays of Inexpensive Disks RPC Remote Procedure Call RTT Round-Trip Time SHA Secure Hash Algorithm SMB Server Message Block SSK Signed-subspace Key VFS Virtual File System TTL Time-to-live xFS Serverless Network File System LISTA DE FIGURAS Figura 1.1: Estrutura do sistema LP2P ...................... 17 Figura 2.1: Estado da página em memória com escrita assíncrona ........ 21 Figura 2.2: Estrutura de um cliente Coda ..................... 25 Figura 2.3: Leitura de um bloco no sistema xFS (fonte: Anderson et al. (1996)) 27 Figura 2.4: Estrutura da rede Gnutella ...................... 29 Figura 2.5: Rede de sobreposição Gnutella com os nodos mal distribuídos .... 30 Figura 2.6: Procura de um arquivo na rede Freenet ................ 33 Figura 2.7: Estrutura do sistema Ivy ........................ 34 Figura 3.1: Funcionamento do LP2P ....................... 41 Figura 3.2: Arquitetura do sistema LP2P ..................... 42 Figura 3.3: Comunicação interna do sistema LP2P ................ 44 Figura 3.4: Estrutura da mensagem LP2P ..................... 44 Figura 3.5: Formato da mensagem llist ...................... 45 Figura 3.6: Formato da mensagem lsendl ..................... 45 Figura 3.7: Formato da mensagem lgetu ..................... 46 Figura 3.8: Formato da mensagem lsendu ..................... 46 Figura 3.9: Formato da mensagem lget ...................... 46 Figura 3.10: Formato da mensagem lsendf ..................... 47 Figura 4.1: A camada de abstração do VFS .................... 49 Figura 4.2: Relações entre os objetos do VFS (fonte: Mauerer (2008)) ..... 54 Figura 4.3: Relação entre as estruturas do VFS e do Page Cache (fonte: Mauerer (2008)) ................................. 56 Figura 4.4: Exemplo de uma árvore radix (fonte: Mauerer (2008)) ........ 58 Figura 4.5: Estrutura com alinhamento de bytes (fonte: Mauerer (2008)) .... 60 Figura 4.6: Montagem do sistema LP2PFS .................... 60 Figura 4.7: Leitura do conteúdo de um arquivo .................. 61 Figura 5.1: Compartilhamento de pacotes Debian ................. 65 Figura 5.2: Vazão de dados usando TCP ..................... 66 Figura 5.3: Latência de comunicação usando TCP ................ 67 Figura 5.4: Vazão individual de cada peer para arquivos de 1 MB ........ 68 Figura 5.5: Vazão individual de cada peer para arquivos de 8 MB ........ 69 Figura 5.6: Vazão individual de cada peer para arquivos de 16 MB ........ 70 Figura 5.7: Vazão agregada do sistema ...................... 71 LISTA DE LISTAGENS Listagem 4.1: Estrutura super_block ....................... 49 Listagem 4.2: Estrutura inode ........................... 50 Listagem 4.3: Estrutura dentry .......................... 51 Listagem 4.4: Estrutura file ........................... 53 Listagem 4.5: Estrutura file_system_type ................... 54 Listagem 4.6: Estrutura address_space ..................... 56 Listagem 4.7: Funções de leitura de páginas .................... 57 Listagem 4.8: Função __builtin_expect .................... 59 Listagem 4.9: Macros likely e unlikely .................... 59 LISTA DE TABELAS Tabela 2.1: Síntese das características dos sistemas estudados .......... 39 Tabela 5.1: Teste do sistema com arquivos de 1 MB ............... 68 Tabela 5.2: Teste do sistema com arquivos de 8 MB ............... 69 Tabela 5.3: Teste do sistema com arquivos de 16 MB ............... 70 Tabela 5.4: Vazão agregada do sistema ...................... 71 RESUMO Sistemas de distribuição de arquivos em rede tem como principal objetivo per- mitir o compartilhamento de dados entre os seus usuários, provendo uma ou mais das seguintes características: transparência de localização, replicação de arquivos, tolerância a falhas, eficiência, segurança e consistência. Nesse contexto, no âm- bito do Programa Interdisciplinar de Pós-Graduação em Computação Aplicada da Unisinos (PIPCA), surgiu a proposta de desenvolver um sistema peer-to-peer para redes locais, o Local Peer-to-Peer Protocol (LP2P), possibilitando a rápida troca de arquivos entre os componentes da rede. Esse sistema, através de seus módulos externos, disponibiliza funções de descoberta de serviços e mecanismos de segurança e otimização para a transferência de arquivos entre os peers da rede. No entanto, é necessário o desenvolvimento de uma interface robusta e de fácil utilização para o sistema. Desse modo, nesse projeto, foi implementado um módulo para o kernel do Linux, que atua como um sistema de arquivos, denominado LP2PFS. Esse módulo permite disponibilizar os arquivos presentes no sistema LP2P, atuando como a sua interface com o usuário. O LP2PFS foi desenvolvido com base na camada de abs- tração do kernel para sistemas de arquivos, o Virtual File System (VFS), utilizando o subsistema de Page Cache para o armazenamento dos dados na memória. O sis- tema de arquivos apresenta as funcionalidades de notificação de eventos ocorridos no sistema às aplicações, através da interface fsnotify, além de possuir um arquivo virtual no sistema Procfs, com dados da sua montagem e dos arquivos presentes no sistema. O módulo LP2PFS obteve êxito em todos os testes executados. A sua implementação é compatível com diversas versões do kernel do Linux e a disponi- bilização dos arquivos presentes no sistema LP2P foi alcançada, sendo comprovada pela verificação da integridade dos dados desses arquivos através do algoritmo MD5. Por fim, foram realizados testes de desempenho do sistema de arquivos em conjunto com o sistema LP2P, através dos quais foi comprovado o desempenho e a eficiência do módulo implementado. Palavras-chave: Sistema de arquivos. peer-to-peer. LP2P. LP2PFS: A VFS Linux Client for the LP2P System ABSTRACT Network file distribution systems aim to allow data sharing among users, pro- viding some of the following features: location transparency, file
Recommended publications
  • Ivoyeur: Inotify
    COLUMNS iVoyeur inotify DAVE JOSEPHSEN Dave Josephsen is the he last time I changed jobs, the magnitude of the change didn’t really author of Building a sink in until the morning of my first day, when I took a different com- Monitoring Infrastructure bination of freeways to work. The difference was accentuated by the with Nagios (Prentice Hall T PTR, 2007) and is Senior fact that the new commute began the same as the old one, but on this morn- Systems Engineer at DBG, Inc., where he ing, at a particular interchange, I would zig where before I zagged. maintains a gaggle of geographically dispersed It was an unexpectedly emotional and profound metaphor for the change. My old place was server farms. He won LISA ‘04’s Best Paper off to the side, and down below, while my future was straight ahead, and literally under award for his co-authored work on spam construction. mitigation, and he donates his spare time to the SourceMage GNU Linux Project. The fact that it was under construction was poetic but not surprising. Most of the roads I [email protected] travel in the Dallas/Fort Worth area are under construction and have been for as long as anyone can remember. And I don’t mean a lane closed here or there. Our roads drift and wan- der like leaves in the water—here today and tomorrow over there. The exits and entrances, neither a part of this road or that, seem unable to anticipate the movements of their brethren, and are constantly forced to react.
    [Show full text]
  • Novell CIFS for Linux Administration Guide 9.4.2 Creating Shared Pools and Accessing Sharepoints
    Open Enterprise Server 11 SP3 Novell CIFS Administration Guide July 2016 Legal Notice For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government rights, patent policy, and FIPS compliance, see https://www.novell.com/company/legal/. Copyright © 2014 - 2016 Novell, Inc. All Rights Reserved. Contents About This Guide 7 1 Overview of CIFS 9 1.1 Understanding CIFS. 9 1.2 CIFS and Universal Password . 10 1.3 CIFS Features and Capabilities . 10 1.4 Limitations . 12 1.5 What's Next . 12 2 What’s New or Changed in Novell CIFS 13 2.1 What’s New (OES11 SP3) . 13 2.2 What’s New (OES11 SP2 May 2016 Patches). 13 2.3 What’s New (OES11 SP2 May 2014 Patches). 13 2.4 What’s New (OES 11 SP1 January 2014 Patches) . 13 2.5 What’s New (OES 11 SP2). 14 2.6 What’s New or Changed in Novell CIFS (OES 11 SP1). 15 2.7 What’s New or Changed in Novell CIFS (OES 11). 15 3 CIFS Monitoring and Management 17 3.1 Overview of CIFS Monitoring and Management . 17 3.2 Using CIFS Monitoring and Management . .17 3.3 Monitoring Connections . 17 3.3.1 Access Modes . 18 3.4 Monitoring Files . 18 4 Planning and Implementing CIFS 21 4.1 Planning for CIFS. 21 4.2 Preparing for CIFS Installation . 21 4.2.1 Prerequisites . 21 4.2.2 Required eDirectory Rights and Permissions . 22 4.3 CIFS System Prerequisites . 24 4.3.1 Server Operating System Requirements .
    [Show full text]
  • OES 2015 SP1: Novell CIFS for Linux Administration Guide
    Open Enterprise Server 2015 SP1 Novell CIFS Administration Guide June 2016 Legal Notice For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government rights, patent policy, and FIPS compliance, see https://www.novell.com/company/legal/. Copyright © 2016 Novell, Inc., a Micro Focus company. All Rights Reserved. Contents About This Guide 9 1 Overview of CIFS 11 1.1 Understanding CIFS. 11 1.2 CIFS and Universal Password . 12 1.3 CIFS Features and Capabilities . 12 1.4 Limitations . 14 1.5 What's Next . 14 2 What’s New or Changed in CIFS 15 2.1 What’s New or Changed in CIFS (Update 33 - OES 2015 SP1) . 15 2.2 What’s New or Changed in CIFS (OES 2015 SP1 September 2017 Patch) . 15 2.3 What’s New or Changed in CIFS (OES 2015 SP1 July 2017 Patch) . 16 2.4 What’s New or Changed in CIFS (OES 2015 SP1 March 2017 Patch) . 16 2.5 What’s New or Changed in CIFS (OES 2015 and OES 2015 SP1 March 2017 Patch). 16 2.6 What’s New or Changed in CIFS (OES 2015 SP1 September 2016 Patch) . 16 2.7 What’s New or Changed in CIFS (OES 2015 SP1) . 17 2.8 What’s New or Changed in CIFS (OES 2015) . 17 3 Planning and Implementing CIFS 21 3.1 Planning for CIFS. 21 3.2 Preparing for CIFS Installation . 21 3.2.1 Prerequisites . 21 3.2.2 Required eDirectory Rights and Permissions . 22 3.3 CIFS System Prerequisites .
    [Show full text]
  • Monitoring File Events
    MONITORING FILE EVENTS Some applications need to be able to monitor files or directories in order to deter- mine whether events have occurred for the monitored objects. For example, a graphical file manager needs to be able to determine when files are added or removed from the directory that is currently being displayed, or a daemon may want to monitor its configuration file in order to know if the file has been changed. Starting with kernel 2.6.13, Linux provides the inotify mechanism, which allows an application to monitor file events. This chapter describes the use of inotify. The inotify mechanism replaces an older mechanism, dnotify, which provided a subset of the functionality of inotify. We describe dnotify briefly at the end of this chapter, focusing on why inotify is better. The inotify and dnotify mechanisms are Linux-specific. (A few other systems provide similar mechanisms. For example, the BSDs provide the kqueue API.) A few libraries provide an API that is more abstract and portable than inotify and dnotify. The use of these libraries may be preferable for some applications. Some of these libraries employ inotify or dnotify, on systems where they are available. Two such libraries are FAM (File Alteration Monitor, http:// oss.sgi.com/projects/fam/) and Gamin (http://www.gnome.org/~veillard/gamin/). 19.1 Overview The key steps in the use of the inotify API are as follows: 1. The application uses inotify_init() to create an inotify instance. This system call returns a file descriptor that is used to refer to the inotify instance in later operations.
    [Show full text]
  • Kernel Korner
    Kernel Korner http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1110000/11030... Kernel Korner Intro to inotify Robert Love Abstract Applications that watch thousands of files for changes, or that need to know when a storage device gets disconnected, need a clean, fast solution to the file change notification problem. Here it is. John McCutchan and I had been working on inotify for about a year when it was finally merged into Linus' kernel tree and released with kernel version 2.6.13. Although a long struggle, the effort culminated in success and was ultimately worth every rewrite, bug and debate. What Is inotify? inotify is a file change notification system—a kernel feature that allows applications to request the monitoring of a set of files against a list of events. When the event occurs, the application is notified. To be useful, such a feature must be simple to use, lightweight with little overhead and flexible. It should be easy to add new watches and painless to receive notification of events. To be sure, inotify is not the first of its kind. Every modern operating system provides some sort of file notification system; many network and desktop applications require such functionality—Linux too. For years, Linux has offered dnotify. The problem was, dnotify was not very good. In fact, it stank. dnotify, which ostensibly stands for directory notify, was never considered easy to use. Sporting a cumbersome interface and several painful features that made life arduous, dnotify failed to meet the demands of the modern desktop, where asynchronous notification of events and a free flow of information rapidly are becoming the norm.
    [Show full text]
  • Displaying and Watching Directories Using Lazarus
    Displaying and Watching directories using Lazarus Michaël Van Canneyt October 31, 2011 Abstract Using Lazarus, getting the contents of a directory can be done in 2 ways: a portable, and a unix-specific way. This article shows how to get the contents of a directory and show it in a window. Additionally, it shows how to get notifications of the Linux kernel if the contents of the directory changes. 1 Introduction Examining the contents of a directory is a common operation, both using command-line tools or a GUI file manager. Naturally, Free/Pascal and Lazarus offer an API to do this. In fact, there are 2 API’s to get the contents of a directory: one which is portable and will work on all platforms supported by Lazarus. The other is not portable, but resembles closely the POSIX API for dealing with files and directories. Each API has its advantages and disadvantages. Often, it is desirable to be notified if the contents of a directory changes: in a file manager, this can be used to update the display - showing new items or removing items as needed. This can also be done by scanning the contents of the directory at regular intervals, but it should be obvious that this is not as efficient. There are other scenarios when a notification of a change in a directory is interesting: for instance, in a FTP server, one may want to move incoming files to a location outside the FTP tree, or to a new location based on some rules (e.g. images to one directory, sound files to another).
    [Show full text]
  • OES 11 SP1: Novell Cluster Services 2.1 for Linux Administration Guide 1 1Overview of Novell Cluster Services
    www.novell.com/documentation Novell Cluster ServicesTM 2.1 for Linux Administration Guide Open Enterprise Server 11 SP1 October 3, 2012 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software.
    [Show full text]
  • Forensic Framework for Honeypot Analysis
    FORENSIC FRAMEWORK FOR HONEYPOT ANALYSIS A Thesis Presented to The Academic Faculty by Kevin D. Fairbanks In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of Electrical and Computer Engineering Georgia Institute of Technology May 2010 Copyright c 2010 by Kevin D. Fairbanks FORENSIC FRAMEWORK FOR HONEYPOT ANALYSIS Approved by: Professor Henry L. Owen, III, Advisor Professor Chuanyi Ji School of Electrical and Computer School of Electrical and Computer Engineering Engineering Georgia Institute of Technology Georgia Institute of Technology Professor John A. Copeland Professor Jonathon T. Giffin School of Electrical and Computer College of Computing Engineering Georgia Institute of Technology Georgia Institute of Technology Professor Raheem A. Beyah Date Approved: March 17th, 2010 School of Electrical and Computer Engineering Georgia Institute of Technology For my grandfather, Willie Lee Fairbanks. You are missed and remembered. iii ACKNOWLEDGEMENTS I have caught enough breaks and had too many of the right people injected in my life throughout the years such that I have garnered a great amount of suspicion about whether or not I have been hurtling through a series of coincidences. I therefore must thank God as I believe that I have been abundantly blessed and without the belief in a higher power, my journeys through the land of academia would have been more harsh and dark than they needed to be. Without the emotional and financial support of my mother and father, Sharron and Whayman Fairbanks Sr, my pursuit of an advanced degree would have either ended pre- maturely or have been extensively protracted. I must also thank my bother and sister, Whayman Jr and Veronica Fairbanks, for being my biggest cheerleaders throughout this process.
    [Show full text]
  • Zack's Kernel News
    Community Notebook Kernel News Zack’s Kernel News Chronicler Zack Simple Flash Filesystem about endianness issues in order to avoid an- Brown reports on Dan Luedtke recently announced LanyFS – a noying, difficult debugging issues further filesystem to use with any drive you might down the road. the latest news, carry on a lanyard or keychain – essentially, Theodore Ts’o came back to the issue of small flash drives. The goal was to make the whether LanyFS was needed at all. He said, views, dilemmas, filesystem so simple that it would work easily “What I would do if I needed to transfer such and developments on any operating system. In this case, the lack a [6MB] file, and I didn’t have access to high of features was itself a feature. speed networking, would be to use ext2, and within the Linux Richard Weinberger and Marco Stornelli then either use the ext2 FUSE driver with didn’t see the point of such minimalism. To FUSE for Windows or Macintosh – or, I would kernel community. them, it just seemed like reinventing the port the userspace e2tools package to the tar- wheel, because other filesystems already ex- get OS, and use that to access the ext2 file By Zack Brown isted with a larger set of features. And, Alan system. And I’d do that because the software Cox gave a link to an interesting article at is available today, right now, without having http:// lwn.net/ Articles/ 428584/ that discussed to figure out how to port LanyFS to the oper- the ins and outs of trying to code a flash-ori- ating system.” ented filesystem.
    [Show full text]
  • Oversubscribing Inotify on Embedded Platforms
    Oversubscribing inotify on Embedded Platforms By Donald Percivalle (CPE) and Scott Vanderlind (CSC) Senior Project California Polytechnic State University San Luis Obispo Dr. Zachary Peterson June 11, 2015 Abstract For most computers running the popular Linux operating system, the inte- grated kernel component inotify provides adequate functionality for monitor- ing changes to files present on the filesystem. However, for certain embedded platforms where resources are very limited and filesystems are very populated (like network attached storage (NAS) devices), inotify may not have enough resources to provide watchers for every file. This results in applications missing change notifications for files they have watched. This paper explores methods for using inotify most effectively on embedded systems by leveraging more la- tent storage. Benefits of this include a reduction in dropped notifications in favor of an introduced delay on notifications for files that are less frequently changed. Contents 1 Introduction 3 1.1 Application . .3 1.2 Problem . .3 1.3 Problem Statement . .4 2 Possible Solutions 5 2.1 Modification of inotify . .5 2.2 Wholesale replacement of inotify . .5 2.3 Development of user-space watch aggregator . .5 2.4 Chosen Approach . .6 2.5 Related Work . .6 3 Design 6 3.1 Constraints . .6 3.2 Implementation . .7 4 Takeaways 8 4.1 Solution Viability . .8 4.2 Future Work . .8 5 Reference Implementation 9 5.1 Driver Application . 10 5.2 Watch Aggregation Module . 12 5.3 Directory Analysis Module . 25 2 1 Introduction as possible. This goal requires a system to monitor the entire filesystem for new Western Digital produces lines of Net- files.
    [Show full text]
  • Monitor and Manage System and Application Configuration Files at Kernel Level in GNU/Linux
    2015-09-23 Monitor and manage system and application configuration files at kernel level in GNU/Linux Saša Stanković DEGREE PROJECT Computer Engineering Bachelor level G2E, 15 hec Department of Engineering Science, University West, Sweden DEGREE PROJECT Monitor and manage system and application configuration files at kernel level in GNU/Linux Summary The aim of this study is to investigate if there is a way a computer can accurately and automatically react on altered configuration file(s) with a minimum of resource utilization and by what means the developer(s) of an application can perform a check of the altered configuration file for their application. In a typical GNU/Linux installation the configuration files are literally counted by the thousands, monitoring these files is a task that for the most part exceeds any system administrator's abilities. Each file has its own syntax that needs to be known by the administrator. Either one of these two tasks could give any system administrator nightmares concerning the difficulty level especially when both tasks are combined. The system administrator could attempt to automate the monitoring tasks together with the syntax checking. There are some tools in the repositories of each distribution for monitoring files but none that lets one monitor and take (predefined or user defined) actions based on what the file monitor reports, the type of file and its contents. A complete tool is not presented in this study, merely a proof of concept that monitoring and taking actions especially with version 2.6.13 (or newer) kernel of GNU/Linux with plugins are quite possible with relatively small computer resource.
    [Show full text]
  • Around the Linux File System World in 45 Minutes
    Around the Linux File System World in 45 minutes Steve French IBM Samba Team [email protected] Abstract lines of code), most active (averaging 10 changesets a day!), and most important kernel subsystems. What makes the Linux file system interface unique? What has improved over the past year in this important part of the kernel? Why are there more than 50 Linux 2 The Linux Virtual File System Layer File Systems? Why might you choose ext4 or XFS, NFS or CIFS, or OCFS2 or GFS2? The differences are not al- The heart of the Linux file system, and what makes ways obvious. This paper will describe the new features Linux file systems unique, is the virtual file system in the Linux VFS, how various Linux file systems dif- layer, or VFS, which they connect to. fer in their use, and compare some of the key Linux file systems. 2.1 Virtual File System Structures and Relation- ships File systems are one of the largest and most active parts of the Linux kernel, but some key sections of the file sys- tem interface are little understood, and with more than The relationships between Linux file system compo- than 50 Linux file systems the differences between them nents is described in various papers [3] and is impor- can be confusing even to developers. tant to understand when carefully comparing file system implementations. 1 Introduction: What is a File System? 2.2 Comparison with other Operating Systems Linux has a rich file system interface, and a surprising number of file system implementations.
    [Show full text]