DOCSLIB.ORG

To FUSE Or Not to FUSE: Performance of User-Space File Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
To FUSE Or Not to FUSE: Performance of User-Space File Systems To FUSE or Not to FUSE: Performance of User-Space File Systems Bharath Kumar Reddy Vangoor, Stony Brook University; Vasily Tarasov, IBM Research-Almaden; Erez Zadok, Stony Brook University https://www.usenix.org/conference/fast17/technical-sessions/presentation/vangoor This paper is included in the Proceedings of the 15th USENIX Conference on File and Storage Technologies (FAST ’17). February 27–March 2, 2017 • Santa Clara, CA, USA ISBN 978-1-931971-36-2 Open access to the Proceedings of the 15th USENIX Conference on File and Storage Technologies is sponsored by USENIX. To FUSE or Not to FUSE: Performance of User-Space File Systems Bharath Kumar Reddy Vangoor1, Vasily Tarasov2, and Erez Zadok1 1Stony Brook University and 2IBM Research—Almaden Abstract whole systems, whereas user-space bugs’ impact is more contained. Many libraries and programming languages Traditionally, file systems were implemented as part are available in user-space in multiple platforms. of OS kernels. However, as complexity of file systems grew, many new file systems began being developed in Although user-space file systems are not expected user space. Nowadays, user-space file systems are often to displace kernel file systems entirely, they undoubt- used to prototype and evaluate new approaches to file edly occupy a growing niche, as some of the more system design. Low performance is considered the main heated debates between proponents and opponents in- disadvantage of user-space file systems but the extent dicate [20,39,41]. The debates center around two trade- of this problem has never been explored systematically. off factors: (1) how large is the performance overhead As a result, the topic of user-space file systems remains caused by a user-space implementations and (2) how rather controversial: while some consider user-space file much easier is it to develop in user space. Ease of de- systems a toy not to be used in production, others de- velopment is highly subjective, hard to formalize and velop full-fledged production file systems in user space. therefore evaluate; but performance is easier to evalu- In this paper we analyze the design and implementa- ate empirically. Oddly, little has been published on the tion of the most widely known user-space file system performance of user-space file system frameworks. framework—FUSE—and characterize its performance In this paper we use a popular user-space file system for a wide range of workloads. We instrumented FUSE framework, FUSE, and characterize its performance. We to extract useful statistics and traces, which helped us an- start with a detailed explanation of FUSE’s design and alyze its performance bottlenecks and present our anal- implementation for four reasons: (1) the architecture is ysis results. Our experiments indicate that depending on somewhat complex; (2) little information on internals is the workload and hardware used, performance degrada- available publicly; (3) FUSE’s source code can be dif- tion caused by FUSE can be completely imperceptible ficult to analyze, with complex asynchrony and user- or as high as –83% even when optimized; and relative kernel communications; and (4) as FUSE’s popularity CPU utilization can increase by 31%. grows, a detailed analysis of its implementation becomes of high value to many. 1 Introduction We developed a simple pass-through stackable file File systems offer a common interface for applications to system in FUSE and then evaluated its performance access data. Although micro-kernels implement file sys- when layered on top of Ext4 compared to native Ext4. tems in user space [1, 16], most file systems are part of We used a wide variety of micro- and macro-workloads, monolithic kernels [6, 22, 34]. Kernel implementations and different hardware using basic and optimized config- avoid the high message-passing overheads of micro- urations of FUSE. We found that depending on the work- kernels and user-space daemons [7, 14]. load and hardware, FUSE can perform as well as Ext4, In recent years, however, user-space file systems but in the worst cases can be 3× slower. Next, we de- rose in popularity for four reasons. (1) Several stack- signed and built a rich instrumentation system for FUSE able file systems add specialized functionality over ex- to gather detailed performance metrics. The statistics ex- isting file systems (e.g., deduplication and compres- tracted are applicable to any FUSE-based systems. We sion [19, 31]). (2) In academia and R&D settings, this then used this instrumentation to identify bottlenecks in framework enabled quick experimentation and prototyp- FUSE, and to explain why, for example, its performance ing of new approaches [3, 9, 15, 21, 40]. (3) Several varied greatly for different workloads. existing kernel-level file systems were ported to user 2 FUSE Design space (e.g., ZFS [45], NTFS [25]). (4) More companies rely on user-space implementations: IBM’S GPFS [30] FUSE—Filesystem in Userspace—is the most widely and LTFS [26], Nimble Storage’s CASL [24], Apache’s used user-space file system framework [35]. According HDFS [2], Google File System [13], RedHat’s Glus- to the most modest estimates, at least 100 FUSE-based terFS [29], Data Domain’s DDFS [46], etc. file systems are readily available on the Web [36]. Al- Increased file systems complexity is a contributing though other, specialized implementations of user-space factor to user-space file systems’ growing popularity file systems exist [30,32,42], we selected FUSE for this (e.g., Btrfs is over 85 KLoC). User space code is eas- study because of its high popularity. ier to develop, port, and maintain. Kernel bugs can crash Although many file systems were implemented using USENIX Association 15th USENIX Conference on File and Storage Technologies 59 FUSE—thanks mainly to the simple API it provides— tem, the daemon reads or writes from the block device. little work was done on understanding its internal ar- When done with processing the request, the FUSE dae- chitecture, implementation, and performance [27]. For mon writes the response back to /dev/fuse; FUSE’s our evaluation it was essential to understand not only kernel driver then marks the request as completed and FUSE’s high-level design but also some details of its im- wakes up the original user process. plementation. In this section we first describe FUSE’s Some file system operations invoked by an application basics and then we explain certain important implemen- can complete without communicating with the user-level tation details. FUSE is available for several OSes: we FUSE daemon. For example, reads from a file whose selected Linux due to its wide-spread use. We analyzed pages are cached in the kernel page cache, do not need the code of and ran experiments on the latest stable ver- to be forwarded to the FUSE driver. sion of the Linux kernel available at the beginning of the project—v4.1.13. We also used FUSE library commit 2.2 Implementation Details #386b1b; on top of FUSE v2.9.4, this commit contains We now discuss several important FUSE implemen- several important patches which we did not want exclude tation details: the user-kernel protocol, library and from our evaluation. We manually examined all new API levels, in-kernel FUSE queues, splicing, multi- commits up to the time of this writing and confirmed threading, and write-back cache. that no new major features or improvements were added to FUSE since the release of the selected versions. Group (#) Request Types Special (3) INIT, DESTROY, INTERRUPT 2.1 High-Level Architecture Metadata (14) LOOKUP, FORGET, BATCH FORGET, CREATE, UNLINK, LINK, RENAME, RE- FUSE file−system daemon NAME2, OPEN, RELEASE, STATFS, Application FSYNC FLUSH ACCESS FUSE library , , User Data (2) READ, WRITE Attributes (2) GETATTR, SETATTR cache /dev/fuse VFS Other kernel Extended SETXATTR, GETXATTR, Q FUSE u subsystems Attributes (4) LISTXATTR, REMOVEXATTR e Kernel Kernel−based driver u Symlinks (2) SYMLINK, READLINK file system e Directory (7) MKDIR, RMDIR, OPENDIR, RE- Figure 1: FUSE high-level architecture. LEASEDIR, READDIR, READDIRPLUS, FUSE consists of a kernel part and a user-level dae- FSYNCDIR Locking (3) GETLK, SETLK, SETLKW mon. The kernel part is implemented as a Linux kernel Misc (6) BMAP, FALLOCATE, MKNOD, IOCTL, module that, when loaded, registers a fuse file-system POLL, NOTIFY REPLY driver with Linux’s VFS. This Fuse driver acts as a proxy for various specific file systems implemented by differ- Table 1: FUSE request types, by group (whose size is in paren- ent user-level daemons. thesis). Requests we discuss in the text are in bold. In addition to registering a new file system, FUSE’s User-kernel protocol. When FUSE’s kernel driver kernel module also registers a /dev/fuse block de- communicates to the user-space daemon, it forms a vice. This device serves as an interface between user- FUSE request structure. Requests have different types space FUSE daemons and the kernel. In general, dae- depending on the operation they convey. Table 1 lists all mon reads FUSE requests from /dev/fuse, processes 43 FUSE request types, grouped by their semantics. As them, and then writes replies back to /dev/fuse. seen, most requests have a direct mapping to traditional Figure 1 shows FUSE’s high-level architecture. When VFS operations: we omit discussion of obvious requests a user application performs some operation on a (e.g., READ, CREATE) and instead next focus on those mounted FUSE file system, the VFS routes the operation less intuitive request types (marked bold in Table 1). to FUSE’s kernel driver. The driver allocates a FUSE The INIT request is produced by the kernel when a request structure and puts it in a FUSE queue.
Load more

Recommended publications
  • Optimizing the Ceph Distributed File System for High Performance Computing
    Optimizing the Ceph Distributed File System for High Performance Computing Kisik Jeong Carl Duffy Jin-Soo Kim Joonwon Lee Sungkyunkwan University Seoul National University Seoul National University Sungkyunkwan University Suwon, South Korea Seoul, South Korea Seoul, South Korea Suwon, South Korea [email protected] [email protected] [email protected] [email protected] Abstract—With increasing demand for running big data ana- ditional HPC workloads. Traditional HPC workloads perform lytics and machine learning workloads with diverse data types, reads from a large shared file stored in a file system, followed high performance computing (HPC) systems consequently need by writes to the file system in a parallel manner. In this case, to support diverse types of storage services. Ceph is one possible candidate for such HPC environments, as Ceph provides inter- a storage service should provide good sequential read/write faces for object, block, and file storage. Ceph, however, is not performance. However, Ceph divides large files into a number designed for HPC environments, thus it needs to be optimized of chunks and distributes them to several different disks. This for HPC workloads. In this paper, we find and analyze problems feature has two main problems in HPC environments: 1) Ceph that arise when running HPC workloads on Ceph, and propose translates sequential accesses into random accesses, 2) Ceph a novel optimization technique called F2FS-split, based on the F2FS file system and several other optimizations. We measure needs to manage many files, incurring high journal overheads the performance of Ceph in HPC environments, and show that in the underlying file system.
    [Show full text]
  • Proxmox Ve Mit Ceph &
    PROXMOX VE MIT CEPH & ZFS ZUKUNFTSSICHERE INFRASTRUKTUR IM RECHENZENTRUM Alwin Antreich Proxmox Server Solutions GmbH FrOSCon 14 | 10. August 2019 Alwin Antreich Software Entwickler @ Proxmox 15 Jahre in der IT als Willkommen! System / Netzwerk Administrator FrOSCon 14 | 10.08.2019 2/33 Proxmox Server Solutions GmbH Aktive Community Proxmox seit 2005 Globales Partnernetz in Wien (AT) Proxmox Mail Gateway Enterprise (AGPL,v3) Proxmox VE (AGPL,v3) Support & Services FrOSCon 14 | 10.08.2019 3/33 Traditionelle Infrastruktur FrOSCon 14 | 10.08.2019 4/33 Hyperkonvergenz FrOSCon 14 | 10.08.2019 5/33 Hyperkonvergente Infrastruktur FrOSCon 14 | 10.08.2019 6/33 Voraussetzung für Hyperkonvergenz CPU / RAM / Netzwerk / Storage Verwende immer genug von allem. FrOSCon 14 | 10.08.2019 7/33 FrOSCon 14 | 10.08.2019 8/33 Was ist ‚das‘? ● Ceph & ZFS - software-basierte Storagelösungen ● ZFS lokal / Ceph verteilt im Netzwerk ● Hervorragende Performance, Verfügbarkeit und https://ceph.io/ Skalierbarkeit ● Verwaltung und Überwachung mit Proxmox VE ● Technischer Support für Ceph & ZFS inkludiert in Proxmox Subskription http://open-zfs.org/ FrOSCon 14 | 10.08.2019 9/33 FrOSCon 14 | 10.08.2019 10/33 FrOSCon 14 | 10.08.2019 11/33 ZFS Architektur FrOSCon 14 | 10.08.2019 12/33 ZFS ARC, L2ARC and ZIL With ZIL Without ZIL ARC RAM ARC RAM ZIL ZIL Application HDD Application SSD HDD FrOSCon 14 | 10.08.2019 13/33 FrOSCon 14 | 10.08.2019 14/33 FrOSCon 14 | 10.08.2019 15/33 Ceph Network Ceph Docs: https://docs.ceph.com/docs/master/ FrOSCon 14 | 10.08.2019 16/33 FrOSCon
    [Show full text]
  • Red Hat Openstack* Platform with Red Hat Ceph* Storage
    Intel® Data Center Blocks for Cloud – Red Hat* OpenStack* Platform with Red Hat Ceph* Storage Reference Architecture Guide for deploying a private cloud based on Red Hat OpenStack* Platform with Red Hat Ceph Storage using Intel® Server Products. Rev 1.0 January 2017 Intel® Server Products and Solutions <Blank page> Intel® Data Center Blocks for Cloud – Red Hat* OpenStack* Platform with Red Hat Ceph* Storage Document Revision History Date Revision Changes January 2017 1.0 Initial release. 3 Intel® Data Center Blocks for Cloud – Red Hat® OpenStack® Platform with Red Hat Ceph Storage Disclaimers Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Learn more at Intel.com, or from the OEM or retailer. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm.
    [Show full text]
  • The Google File System (GFS)
    The Google File System (GFS), as described by Ghemwat, Gobioff, and Leung in 2003, provided the architecture for scalable, fault-tolerant data management within the context of Google. These architectural choices, however, resulted in sub-optimal performance in regard to data trustworthiness (security) and simplicity. Additionally, the application- specific nature of GFS limits the general scalability of the system outside of the specific design considerations within the context of Google. SYSTEM DESIGN: The authors enumerate their specific considerations as: (1) commodity components with high expectation of failure, (2) a system optimized to handle relatively large files, particularly multi-GB files, (3) most writes to the system are concurrent append operations, rather than internally modifying the extant files, and (4) a high rate of sustained bandwidth (Section 1, 2.1). Utilizing these considerations, this paper analyzes the success of GFS’s design in achieving a fault-tolerant, scalable system while also considering the faults of the system with regards to data-trustworthiness and simplicity. Data-trustworthiness: In designing the GFS system, the authors made the conscious decision not prioritize data trustworthiness by allowing applications to access ‘stale’, or not up-to-date, data. In particular, although the system does inform applications of the chunk-server version number, the designers of GFS encouraged user applications to cache chunkserver information, allowing stale data accesses (Section 2.7.2, 4.5). Although possibly troubling
    [Show full text]
  • A Review on GOOGLE File System
    International Journal of Computer Science Trends and Technology (IJCST) – Volume 4 Issue 4, Jul - Aug 2016 RESEARCH ARTICLE OPEN ACCESS A Review on Google File System Richa Pandey [1], S.P Sah [2] Department of Computer Science Graphic Era Hill University Uttarakhand – India ABSTRACT Google is an American multinational technology company specializing in Internet-related services and products. A Google file system help in managing the large amount of data which is spread in various databases. A good Google file system is that which have the capability to handle the fault, the replication of data, make the data efficient, memory storage. The large data which is big data must be in the form that it can be managed easily. Many applications like Gmail, Facebook etc. have the file systems which organize the data in relevant format. In conclusion the paper introduces new approaches in distributed file system like spreading file’s data across storage, single master and appends writes etc. Keywords:- GFS, NFS, AFS, HDFS I. INTRODUCTION III. KEY IDEAS The Google file system is designed in such a way that 3.1. Design and Architecture: GFS cluster consist the data which is spread in database must be saved in of single master and multiple chunk servers used by a arrange manner. multiple clients. Since files to be stored in GFS are The arrangement of data is in the way that it can large, processing and transferring such huge files can reduce the overhead load on the server, the consume a lot of bandwidth. To efficiently utilize availability must be increased, throughput should be bandwidth files are divided into large 64 MB size highly aggregated and much more services to make chunks which are identified by unique 64-bit chunk the available data more accurate and reliable.
    [Show full text]
  • Gluster Roadmap: Recent Improvements and Upcoming Features
    Gluster roadmap: Recent improvements and upcoming features Niels de Vos GlusterFS co-maintainer [email protected] Agenda ● Introduction into Gluster ● Quick Start ● Current stable releases ● History of feature additions ● Plans for the upcoming 3.8 and 4.0 release ● Detailed description of a few select features FOSDEM, 30 January 2016 2 What is GlusterFS? ● Scalable, general-purpose storage platform ● POSIX-y Distributed File System ● Object storage (swift) ● Distributed block storage (qemu) ● Flexible storage (libgfapi) ● No Metadata Server ● Heterogeneous Commodity Hardware ● Flexible and Agile Scaling ● Capacity – Petabytes and beyond ● Performance – Thousands of Clients FOSDEM, 30 January 2016 3 Terminology ● Brick ● Fundamentally, a filesystem mountpoint ● A unit of storage used as a capacity building block ● Translator ● Logic between the file bits and the Global Namespace ● Layered to provide GlusterFS functionality FOSDEM, 30 January 2016 4 Terminology ● Volume ● Bricks combined and passed through translators ● Ultimately, what's presented to the end user ● Peer / Node ● Server hosting the brick filesystems ● Runs the Gluster daemons and participates in volumes ● Trusted Storage Pool ● A group of peers, like a “Gluster cluster” FOSDEM, 30 January 2016 5 Scale-out and Scale-up FOSDEM, 30 January 2016 6 Distributed Volume ● Files “evenly” spread across bricks ● Similar to file-level RAID 0 ● Server/Disk failure could be catastrophic FOSDEM, 30 January 2016 7 Replicated Volume ● Copies files to multiple bricks ● Similar to file-level
    [Show full text]
  • Storage Virtualization for KVM – Putting the Pieces Together
    Storage Virtualization for KVM – Putting the pieces together Bharata B Rao – [email protected] Deepak C Shettty – [email protected] M Mohan Kumar – [email protected] (IBM Linux Technology Center, Bangalore) Balamurugan Aramugam - [email protected] Shireesh Anjal – [email protected] (RedHat, Bangalore) Aug 2012 LPC2012 Linux is a registered trademark of Linus Torvalds. Agenda ● Problems around storage in virtualization ● GlusterFS as virt-ready file system – QEMU-GlusterFS integration – GlusterFS – Block device translator ● Virtualization management - oVirt and VDSM – VDSM-GlusterFS integration ● Storage integration – libstoragemgmt Problems in storage/FS in KVM virtualization ● Multiple choices for file system and virtualization management ● Lack of virtualization aware file systems ● File systems/storage functionality implemented in other layers of virtualization stack – Snapshots, block streaming, image formats in QEMU ● No well defined interface points in the virtualization stack for storage integration ● No standard interface/APIs available for services like backup and restore ● Need for a single FS/storage solution that works for local, SAN and NAS storage – Mixing different types of storage into a single filesystem namespace GlusterFS ● User space distributed file system that scales to several petabytes ● Aggregates storage resources from multiple nodes and presents a unified file system namespace GlusterFS - features ● Replication ● Striping ● Distribution ● Geo-replication/sync ● Online volume extension
    [Show full text]
  • Red Hat Data Analytics Infrastructure Solution
    TECHNOLOGY DETAIL RED HAT DATA ANALYTICS INFRASTRUCTURE SOLUTION TABLE OF CONTENTS 1 INTRODUCTION ................................................................................................................ 2 2 RED HAT DATA ANALYTICS INFRASTRUCTURE SOLUTION ..................................... 2 2.1 The evolution of analytics infrastructure ....................................................................................... 3 Give data scientists and data 2.2 Benefits of a shared data repository on Red Hat Ceph Storage .............................................. 3 analytics teams access to their own clusters without the unnec- 2.3 Solution components ...........................................................................................................................4 essary cost and complexity of 3 TESTING ENVIRONMENT OVERVIEW ............................................................................ 4 duplicating Hadoop Distributed File System (HDFS) datasets. 4 RELATIVE COST AND PERFORMANCE COMPARISON ................................................ 6 4.1 Findings summary ................................................................................................................................. 6 Rapidly deploy and decom- 4.2 Workload details .................................................................................................................................... 7 mission analytics clusters on 4.3 24-hour ingest ........................................................................................................................................8
    [Show full text]
  • Glusterfs Documentation Release 3.8.0
    GlusterFS Documentation Release 3.8.0 Gluster Community Aug 10, 2016 Contents 1 Quick Start Guide 3 1.1 Single Node Cluster...........................................3 1.2 Multi Node Cluster............................................4 2 Overview and Concepts 7 2.1 Volume Types..............................................7 2.2 FUSE................................................... 10 2.3 Translators................................................ 12 2.4 Geo-Replication............................................. 17 2.5 Terminologies.............................................. 19 3 Installation Guide 23 3.1 Getting Started.............................................. 23 3.2 Configuration............................................... 24 3.3 Installing Gluster............................................. 26 3.4 Overview................................................. 27 3.5 Quick Start Guide............................................ 28 3.6 Setup Baremetal............................................. 29 3.7 Deploying in AWS............................................ 30 3.8 Setting up in virtual machines...................................... 31 4 Administrator Guide 33 5 Upgrade Guide 35 6 Contributors Guide 37 6.1 Adding your blog............................................. 37 6.2 Bug Lifecycle.............................................. 37 6.3 Bug Reporting Guidelines........................................ 38 6.4 Bug Triage Guidelines.......................................... 41 7 Changelog 47 8 Presentations 49 i ii GlusterFS
    [Show full text]
  • F1 Query: Declarative Querying at Scale
    F1 Query: Declarative Querying at Scale Bart Samwel John Cieslewicz Ben Handy Jason Govig Petros Venetis Chanjun Yang Keith Peters Jeff Shute Daniel Tenedorio Himani Apte Felix Weigel David Wilhite Jiacheng Yang Jun Xu Jiexing Li Zhan Yuan Craig Chasseur Qiang Zeng Ian Rae Anurag Biyani Andrew Harn Yang Xia Andrey Gubichev Amr El-Helw Orri Erling Zhepeng Yan Mohan Yang Yiqun Wei Thanh Do Colin Zheng Goetz Graefe Somayeh Sardashti Ahmed M. Aly Divy Agrawal Ashish Gupta Shiv Venkataraman Google LLC [email protected] ABSTRACT 1. INTRODUCTION F1 Query is a stand-alone, federated query processing platform The data processing and analysis use cases in large organiza- that executes SQL queries against data stored in different file- tions like Google exhibit diverse requirements in data sizes, la- based formats as well as different storage systems at Google (e.g., tency, data sources and sinks, freshness, and the need for custom Bigtable, Spanner, Google Spreadsheets, etc.). F1 Query elimi- business logic. As a result, many data processing systems focus on nates the need to maintain the traditional distinction between dif- a particular slice of this requirements space, for instance on either ferent types of data processing workloads by simultaneously sup- transactional-style queries, medium-sized OLAP queries, or huge porting: (i) OLTP-style point queries that affect only a few records; Extract-Transform-Load (ETL) pipelines. Some systems are highly (ii) low-latency OLAP querying of large amounts of data; and (iii) extensible, while others are not. Some systems function mostly as a large ETL pipelines. F1 Query has also significantly reduced the closed silo, while others can easily pull in data from other sources.
    [Show full text]
  • A Study of Cryptographic File Systems in Userspace
    Turkish Journal of Computer and Mathematics Education Vol.12 No.10 (2021), 4507-4513 Research Article A study of cryptographic file systems in userspace a b c d e f Sahil Naphade , Ajinkya Kulkarni Yash Kulkarni , Yash Patil , Kaushik Lathiya , Sachin Pande a Department of Information Technology PICT, Pune, India [email protected] b Department of Information Technology PICT, Pune, India [email protected] c Department of Information Technology PICT, Pune, India [email protected] d Department of Information Technology PICT, Pune, India [email protected] e Veritas Technologies Pune, India, [email protected] f Department of Information Technology PICT, Pune, India [email protected] Article History: Received: 10 January 2021; Revised: 12 February 2021; Accepted: 27 March 2021; Published online: 28 April 2021 Abstract: With the advancements in technology and digitization, the data storage needs are expanding; along with the data breaches which can expose sensitive data to the world. Thus, the security of the stored data is extremely important. Conventionally, there are two methods of storage of the data, the first being hiding the data and the second being encryption of the data. However, finding out hidden data is simple, and thus, is very unreliable. The second method, which is encryption, allows for accessing the data by only the person who encrypted the data using his passkey, thus allowing for higher security. Typically, a file system is implemented in the kernel of the operating systems. However, with an increase in the complexity of the traditional file systems like ext3 and ext4, the ones that are based in the userspace of the OS are now allowing for additional features on top of them, such as encryption-decryption and compression.
    [Show full text]
  • Unlock Bigdata Analytic Efficiency with Ceph Data Lake
    Unlock Bigdata Analytic Efficiency With Ceph Data Lake Jian Zhang, Yong Fu, March, 2018 Agenda . Background & Motivations . The Workloads, Reference Architecture Evolution and Performance Optimization . Performance Comparison with Remote HDFS . Summary & Next Step 3 Challenges of scaling Hadoop* Storage BOUNDED Storage and Compute resources on Hadoop Nodes brings challenges Data Capacity Silos Costs Performance & efficiency Typical Challenges Data/Capacity Multiple Storage Silos Space, Spent, Power, Utilization Upgrade Cost Inadequate Performance Provisioning And Configuration Source: 451 Research, Voice of the Enterprise: Storage Q4 2015 *Other names and brands may be claimed as the property of others. 4 Options To Address The Challenges Compute and Large Cluster More Clusters Storage Disaggregation • Lacks isolation - • Cost of • Isolation of high- noisy neighbors duplicating priority workloads hinder SLAs datasets across • Shared big • Lacks elasticity - clusters datasets rigid cluster size • Lacks on-demand • On-demand • Can’t scale provisioning provisioning compute/storage • Can’t scale • compute/storage costs separately compute/storage costs scale costs separately separately Compute and Storage disaggregation provides Simplicity, Elasticity, Isolation 5 Unified Hadoop* File System and API for cloud storage Hadoop Compatible File System abstraction layer: Unified storage API interface Hadoop fs –ls s3a://job/ adl:// oss:// s3n:// gs:// s3:// s3a:// wasb:// 2006 2008 2014 2015 2016 6 Proposal: Apache Hadoop* with disagreed Object Storage SQL …… Hadoop Services • Virtual Machine • Container • Bare Metal HCFS Compute 1 Compute 2 Compute 3 … Compute N Object Storage Services Object Object Object Object • Co-located with gateway Storage 1 Storage 2 Storage 3 … Storage N • Dynamic DNS or load balancer • Data protection via storage replication or erasure code Disaggregated Object Storage Cluster • Storage tiering *Other names and brands may be claimed as the property of others.
    [Show full text]