DOCSLIB.ORG

Silicon Graphics, Inc. Scalable Filesystems XFS & CXFS

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Silicon Graphics, Inc. Scalable Filesystems XFS & CXFS Silicon Graphics, Inc. Scalable Filesystems XFS & CXFS Presented by: Yingping Lu January 31, 2007 Outline • XFS Overview •XFS Architecture • XFS Fundamental Data Structure – Extent list –B+Tree – Inode • XFS Filesystem On-Disk Layout • XFS Directory Structure • CXFS: shared file system ||January 31, 2007 Page 2 XFS: A World-Class File System –Scalable • Full 64 bit support • Dynamic allocation of metadata space • Scalable structures and algorithms –Fast • Fast metadata speeds • High bandwidths • High transaction rates –Reliable • Field proven • Log/Journal ||January 31, 2007 Page 3 Scalable –Full 64 bit support • Large Filesystem – 18,446,744,073,709,551,615 = 264-1 = 18 million TB (exabytes) • Large Files – 9,223,372,036,854,775,807 = 263-1 = 9 million TB (exabytes) – Dynamic allocation of metadata space • Inode size configurable, inode space allocated dynamically • Unlimited number of files (constrained by storage space) – Scalable structures and algorithms (B-Trees) • Performance is not an issue with large numbers of files and directories ||January 31, 2007 Page 4 Fast –Fast metadata speeds • B-Trees everywhere (Nearly all lists of metadata information) – Directory contents – Metadata free lists – Extent lists within file – High bandwidths (Storage: RM6700) • 7.32 GB/s on one filesystem (32p Origin2000, 897 FC disks) • >4 GB/s in one file (same Origin, 704 FC disks) • Large extents (4 KB to 4 GB) • Request parallelism (multiple AGs) • Delayed allocation, Read ahead/Write behind – High transaction rates: 92,423 IOPS (Storage: TP9700) ||January 31, 2007 Page 5 Reliable – Field proven • Run for years on 100s of 1,000 of IRIX systems for over a decade • Ships as default filesystem on SGI Altix family : 64-bit Linux • Commercial vendors shipping XFS – Ciprico DiMeda NAS Solutions, The Quantum Guardian™ 14000, BigStorage K2~NAS, Echostar DishPVR 721, Sun Cobalt RaQ™ 550 • Linux Distributions shipping XFS – Mandrake Linux, SuSE Linux, Gentoo Linux, Slackware Linux, JB Linux • Now in Linux Kernel – Log/Journal • XFS designed around log • No UNIX fsck is needed • Recovery time is independent of system size – Depends on system activity levels • Usually, recovery completes in under a second ||January 31, 2007 Page 6 Other XFS Features – Large Range of Block Sizes (512 B to 64 KB) – Extended attributes – Sparse files (holes do not use disk space) – Guaranteed rate I/O – Online Dump, Resize, Defrag active file systems – DMAPI interface supported (for HSM) – Support real-time file stream – Run on IRIX, Linux, FreeBSD ||January 31, 2007 Page 7 The System Architecture (Linux) User mount open read write lseek System call Kernel VFS FS drv nfs XFS ext2 ext3 Cache Manager Scsi drv st sd sr SCSI middle layer HBA drv qla2200 ||January 31, 2007 Page 8 XFS Architecture XVM ||January 31, 2007 Page 9 Inode Structure –IO Core component xfs_dinode_t • Time stamp, size, ino di_core (96 bytes) xfs_dinode_t • Formats of two other components –Data component (union) di_next_unlink (4 bytes) • Btree/extent list • Symbolic link/small data di_u data fork • Small directory list –Attribute component (union) di_a extended attribute fork • Btree/extent list • Local attributes ||January 31, 2007 Page 10 Extent • An extent is a number of contiguous file blocks • The minimal size of an extent is one file block • Extent is represented as a triple: start file system block, number of blocks and flag • Extent can significantly reduce the space used to record the allocated and free space if space has a large number of contiguous blocks • For a regular file, extent also includes the file offset. • With extents, sparse files, i.e. potential “holes” in file are supported. ||January 31, 2007 Page 11 Extent List Mapping size 0 time … 4 blocks 20 mode 3 … 23 dformat=extent 4 aformat=local <0, 20, 4, 0> … 10 blocks <4, 32, 10, 0> 32 <16, 50, 5, 0> 13 … total Hole Count 41 nlen 16 vlen … 5 blocks name 20 value 50 … 54 Inode File space File system space ||January 31, 2007 Page 12 Data B+tree 7 size level=2 time numrecs=3 Root node mode file offset/fs block 0/13|5000/14|9800/15 dformat=btree intermediate nodes aformat=local 13 14 15 level=2 level=1 level=1 level=1 numrecs=1 numrecs=50 numrecs=50 numrecs=32 off (0)/fs block(7) file offset/fs block file offset/fs block file offset/fs block 0/40|100/51|200/55 5000/120|5100/121|51 9800/802|9910/803|10 total 290/56| … 90/122 005/805 Count … … 40 51 nlen level=0 level=0 vlen numrecs=50 numrecs=50 name file offset/fs blk/#blk file offset/fs blk/#blk value 0/201/2|2/206/2 100/311/2|102/317/2 4/210/3|7/218/1 104/325/4|110/340/3 leave nodes … … Inode ||January 31, 2007 Page 13 File System On-Disk Layout A File System AG0 AG1 AG2 … AG: Allocation Group SB AGF AGFL AGI FDB1 FDB2 … SB: Super Block (1 sector, xfs_sb_t) AGF: Allocation Group Free Space (1 sector, xfs_agf_t) AGI: Allocation Group Inode (1 sector, xfs_agi_t) AGFL: Allocation Group Freelist (1 sector, xfs_agfl_t) FDB: File Data Block (file block size: 4K(default)) ||January 31, 2007 Page 14 AGF B+Tree ||January 31, 2007 Page 15 AGF B+Tree (2 levels) ||January 31, 2007 Page 16 AGI B+Tree ||January 31, 2007 Page 17 Inode Allocation • Inode size – Configurable at FS creation time – Can be 256B, 512B, up to 4096B • Inode allocation – Allocation unit is a cluster, 64 inodes – Inode mask to show which inodes are free • Inode number consists of: –AG # – FS Block # for the inode cluster – Index within a cluster ||January 31, 2007 Page 18 XFS Directory Structure • Unix files are organized in an inverted tree structure • Each directory has a list of files under its directory • Each entry in a directory represents an file object, or a logical link or a sub-directory • Each entry has the object name, the length of name, the corresponding inode number • Directory data are usually stored in directory blocks, the size of a directory block is multiple of file data block size. Superblock’s sb_dirblklog designates the size. It can range from 4KB to 64KB ||January 31, 2007 Page 19 Directory Forms • Directory data – Directory entries (name, len, ino, offset) – Leaf array: hash/address for lookup – Freeindex array for allocation • Directory forms – Shortform directory: Directory data stored within inode – Block directory: 1 extent, All directory entries stored within a directory block – Leaf directory: extent list, Multiple data blocks, one leaf block – Node directory: extent list, Multiple data blocks, B+tree like leaf blocks – B+tree directory: btree format for data fork • The system dynamically adjusts the format with the addition or removal of the directory entries ||January 31, 2007 Page 20 Shortform Directory ||January 31, 2007 Page 21 Block Directory • Use a directory block to store directory entries • The location of the block is stored in the inode’s incore extent list: the di_u.u_bmx[0] • The directory blocks (xfs_dir2_block_t) has the following data fields: – A header specifies the magic number and freespace list (3 largest free space) – Directory entry list (name len, name, ino, offset) – Leaf array: contains an array of hashval/address pairs for quickly looking up a name by the hash value. – Tail structure specifies the number of elements in the leaf array and the number of stale entries in the array. The tail is always located at the end of the block. ||January 31, 2007 Page 22 ||January 31, 2007 Page 23 Leaf Directory • When the # of directory entries cannot be stored in one block, we use extent list to store directory entries • Data and leaf are split into different blocks. • One or more data blocks, each directory data block has its own header and bestfree list • Only one leaf block (the last one). Leaf block has its own header, hash/address array, best free space array maintains each data block’s bestfree[0]’s length. The tail part has the number of bestfree elements ||January 31, 2007 Page 24 Leaf Block ||January 31, 2007 Page 25 Node Directory • When leaf fills a block, another separation is needed. • The “data” blocks are the same as leaf directory • The leaf blocks are changed into B+tree with generic header pointing to directory “leaves”. • A new freeindex block contains the best for each data block • The location of the leaf blocks can be in any order, the only way to determine the appropriate is by the node block hash/before values. ||January 31, 2007 Page 26 B+Tree-style Leaf Blocks leaf blocks Node block ||January 31, 2007 Page 27 B+Tree Directory • With very large number of directory entries, inode format is changed to B+tree • B+tree extents contains extent maps for data (directory entries), node, leaf(hash/address), freeindex. • The node/leaf trees can be more than one level • More than one freelist may exist ||January 31, 2007 Page 28 CXFS Clustered File System Fibre Channel Storage Area Network Full standard Unix interface Near-local file As easy to share files performance from as with NFS, but faster direct data channels Fully resilient (HA) ||January 31, 2007 Page 29 CXFS Concepts –Metadata • The data about a file, including: • size, inode, create/modify times, and permissions –Metadata server node (a.k.a. CXFS server) • One machine in the cluster that is responsible for controlling the metadata of files. Plays “traffic cop” to control access to the file. –Metadata client node (a.k.a. CXFS client) • A machine in the cluster that is not the metadata server. Must obtain permission from metadata server before accessing the file. –Single server manages metadata • Backup metadata servers designated for fail-over • No single point of failure ||January 31, 2007 Page 30 CXFS networks • Besides the storage area network CXFS uses the following networks: – Metadata network • IP network (dedicated) for metadata and tokens – Membership network • IP network used for heart beating – Reset network between metadata servers • non IP serial lines used to reset nodes – I/O Fencing • SAN switch port disable/enable ||January 31, 2007 Page 31 Data Integrity - IO fencing • CXFS nodes all have direct access to FC storage.
Load more

Recommended publications
  • Early Experiences with Storage Area Networks and CXFS John Lynch
    Early Experiences with Storage Area Networks and CXFS John Lynch Aerojet 6304 Spine Road Boulder CO 80516 Abstract This paper looks at the design, integration and application issues involved in deploying an early access, very large, and highly available storage area network. Covered are topics from filesystem failover, issues regarding numbers of nodes in a cluster, and using leading edge solutions to solve complex issues in a real-time data processing network. 1 Introduction SAN technology can be categorized in two distinct approaches. Both Aerojet designed and installed a highly approaches use the storage area network available, large scale Storage Area to provide access to multiple storage Network over spring of 2000. This devices at the same time by one or system due to it size and diversity is multiple hosts. The difference is how known to be one of a kind and is the storage devices are accessed. currently not offered by SGI, but would serve as a prototype system. The most common approach allows the hosts to access the storage devices across The project’s goal was to evaluate Fibre the storage area network but filesystems Channel and SAN technology for its are not shared. This allows either a benefits and applicability in a second- single host to stripe data across a greater generation, real-time data processing number of storage controllers, or to network. SAN technology seemed to be share storage controllers among several the technology of the future to replace systems. This essentially breaks up a the traditional SCSI solution. large storage system into smaller distinct pieces, but allows for the cost-sharing of The approach was to conduct and the most expensive component, the evaluation of SAN technology as a storage controller.
    [Show full text]
  • CXFSTM Client-Only Guide for SGI® Infinitestorage
    CXFSTM Client-Only Guide for SGI® InfiniteStorage 007–4507–016 COPYRIGHT © 2002–2008 SGI. All rights reserved; provided portions may be copyright in third parties, as indicated elsewhere herein. No permission is granted to copy, distribute, or create derivative works from the contents of this electronic documentation in any manner, in whole or in part, without the prior written permission of SGI. LIMITED RIGHTS LEGEND The software described in this document is "commercial computer software" provided with restricted rights (except as to included open/free source) as specified in the FAR 52.227-19 and/or the DFAR 227.7202, or successive sections. Use beyond license provisions is a violation of worldwide intellectual property laws, treaties and conventions. This document is provided with limited rights as defined in 52.227-14. TRADEMARKS AND ATTRIBUTIONS SGI, Altix, the SGI cube and the SGI logo are registered trademarks and CXFS, FailSafe, IRIS FailSafe, SGI ProPack, and Trusted IRIX are trademarks of SGI in the United States and/or other countries worldwide. Active Directory, Microsoft, Windows, and Windows NT are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. AIX and IBM are registered trademarks of IBM Corporation. Brocade and Silkworm are trademarks of Brocade Communication Systems, Inc. AMD, AMD Athlon, AMD Duron, and AMD Opteron are trademarks of Advanced Micro Devices, Inc. Apple, Mac, Mac OS, Power Mac, and Xserve are registered trademarks of Apple Computer, Inc. Disk Manager is a registered trademark of ONTRACK Data International, Inc. Engenio, LSI Logic, and SANshare are trademarks or registered trademarks of LSI Corporation.
    [Show full text]
  • W4118: File Systems
    W4118: file systems Instructor: Junfeng Yang References: Modern Operating Systems (3rd edition), Operating Systems Concepts (8th edition), previous W4118, and OS at MIT, Stanford, and UWisc Outline File system concepts . What is a file? . What operations can be performed on files? . What is a directory and how is it organized? File implementation . How to allocate disk space to files? 1 What is a file User view . Named byte array • Types defined by user . Persistent across reboots and power failures OS view . Map bytes as collection of blocks on physical storage . Stored on nonvolatile storage device • Magnetic Disks 2 Role of file system Naming . How to “name” files . Translate “name” + offset logical block # Reliability . Must not lose file data Protection . Must mediate file access from different users Disk management . Fair, efficient use of disk space . Fast access to files 3 File metadata Name – only information kept in human-readable form Identifier – unique tag (number) identifies file within file system (inode number in UNIX) Location – pointer to file location on device Size – current file size Protection – controls who can do reading, writing, executing Time, date, and user identification – data for protection, security, and usage monitoring How is metadata stored? (inode in UNIX) 4 File operations int creat(const char* pathname, mode_t mode) int unlink(const char* pathname) int rename(const char* oldpath, const char* newpath) int open(const char* pathname, int flags, mode_t mode) int read(int fd, void* buf, size_t count); int write(int fd, const void* buf, size_t count) int lseek(int fd, offset_t offset, int whence) int truncate(const char* pathname, offset_t len) ..
    [Show full text]
  • Lecture 17: Files and Directories
    11/1/16 CS 422/522 Design & Implementation of Operating Systems Lecture 17: Files and Directories Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous versions of the CS422/522 lectures taught by Prof. Bryan Ford and Dr. David Wolinsky, and also from the official set of slides accompanying the OSPP textbook by Anderson and Dahlin. The big picture ◆ Lectures before the fall break: – Management of CPU & concurrency – Management of main memory & virtual memory ◆ Current topics --- “Management of I/O devices” – Last week: I/O devices & device drivers – Last week: storage devices – This week: file systems * File system structure * Naming and directories * Efficiency and performance * Reliability and protection 1 11/1/16 This lecture ◆ Implementing file system abstraction Physical Reality File System Abstraction block oriented byte oriented physical sector #’s named files no protection users protected from each other data might be corrupted robust to machine failures if machine crashes File system components ◆ Disk management User – Arrange collection of disk blocks into files File File ◆ Naming Naming access – User gives file name, not track or sector number, to locate data Disk management ◆ Security / protection – Keep information secure Disk drivers ◆ Reliability/durability – When system crashes, lose stuff in memory, but want files to be durable 2 11/1/16 User vs. system view of a file ◆ User’s view – Durable data structures ◆ System’s view (system call interface) – Collection of bytes (Unix) ◆ System’s view (inside OS): – Collection of blocks – A block is a logical transfer unit, while a sector is the physical transfer unit.
    [Show full text]
  • CXFSTM Administration Guide for SGI® Infinitestorage
    CXFSTM Administration Guide for SGI® InfiniteStorage 007–4016–025 CONTRIBUTORS Written by Lori Johnson Illustrated by Chrystie Danzer Engineering contributions to the book by Vladmir Apostolov, Rich Altmaier, Neil Bannister, François Barbou des Places, Ken Beck, Felix Blyakher, Laurie Costello, Mark Cruciani, Rupak Das, Alex Elder, Dave Ellis, Brian Gaffey, Philippe Gregoire, Gary Hagensen, Ryan Hankins, George Hyman, Dean Jansa, Erik Jacobson, John Keller, Dennis Kender, Bob Kierski, Chris Kirby, Ted Kline, Dan Knappe, Kent Koeninger, Linda Lait, Bob LaPreze, Jinglei Li, Yingping Lu, Steve Lord, Aaron Mantel, Troy McCorkell, LaNet Merrill, Terry Merth, Jim Nead, Nate Pearlstein, Bryce Petty, Dave Pulido, Alain Renaud, John Relph, Elaine Robinson, Dean Roehrich, Eric Sandeen, Yui Sakazume, Wesley Smith, Kerm Steffenhagen, Paddy Sreenivasan, Roger Strassburg, Andy Tran, Rebecca Underwood, Connie Woodward, Michelle Webster, Geoffrey Wehrman, Sammy Wilborn COPYRIGHT © 1999–2007 SGI. All rights reserved; provided portions may be copyright in third parties, as indicated elsewhere herein. No permission is granted to copy, distribute, or create derivative works from the contents of this electronic documentation in any manner, in whole or in part, without the prior written permission of SGI. LIMITED RIGHTS LEGEND The software described in this document is "commercial computer software" provided with restricted rights (except as to included open/free source) as specified in the FAR 52.227-19 and/or the DFAR 227.7202, or successive sections. Use beyond
    [Show full text]
  • Oracle® Linux 7 Managing File Systems
    Oracle® Linux 7 Managing File Systems F32760-07 August 2021 Oracle Legal Notices Copyright © 2020, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Operating Systems Lecture #5: File Management
    Operating Systems Lecture #5: File Management Written by David Goodwin based on the lecture series of Dr. Dayou Li and the book Understanding Operating Systems 4thed. by I.M.Flynn and A.McIver McHoes (2006) Department of Computer Science and Technology, University of Bedfordshire. Operating Systems, 2013 25th February 2013 Outline Lecture #5 File Management David Goodwin 1 Introduction University of Bedfordshire 2 Interaction with the file manager Introduction Interaction with the file manager 3 Files Files Physical storage 4 Physical storage allocation allocation Directories 5 Directories File system Access 6 File system Data compression summary 7 Access 8 Data compression 9 summary Operating Systems 46 Lecture #5 File Management David Goodwin University of Bedfordshire Introduction 3 Interaction with the file manager Introduction Files Physical storage allocation Directories File system Access Data compression summary Operating Systems 46 Introduction Lecture #5 File Management David Goodwin University of Bedfordshire Introduction 4 Responsibilities of the file manager Interaction with the file manager 1 Keep track of where each file is stored Files 2 Use a policy that will determine where and how the files will Physical storage be stored, making sure to efficiently use the available storage allocation space and provide efficient access to the files. Directories 3 Allocate each file when a user has been cleared for access to File system it, and then record its use. Access 4 Deallocate the file when the file is to be returned to storage, Data compression and communicate its availability to others who may be summary waiting for it. Operating Systems 46 Definitions Lecture #5 File Management field is a group of related bytes that can be identified by David Goodwin University of the user with a name, type, and size.
    [Show full text]
  • Introduction to ISO 9660
    Disc Manufacturing, Inc. A QUIXOTE COMPANY Introduction to ISO 9660, what it is, how it is implemented, and how it has been extended. Clayton Summers Copyright © 1993 by Disc Manufacturing, Inc. All rights reserved. WHO IS DMI? Disc Manufacturing, Inc. (DMI) manufactures all compact disc formats (i.e., CD-Audio, CD-ROM, CD-ROM XA, CDI, PHOTO CD, 3DO, KARAOKE, etc.) at two plant sites in the U.S.; Huntsville, AL, and Anaheim, CA. To help you, DMI has one of the largest Product Engineering/Technical Support staff and sales force dedicated solely to CD-ROM in the industry. The company has had a long term commitment to optical disc technology and has performed developmental work and manufactured (laser) optical discs of various types since 1981. In 1983, DMI manufactured the first compact disc in the United States. DMI has developed extensive mastering expertise during this time and is frequently called upon by other companies to provide special mastering services for products in development. In August 1991, DMI purchased the U.S. CD-ROM business from the Philips and Du Pont Optical Company (PDO). PDO employees in sales, marketing and technical services were retained. DMI is a wholly-owned subsidiary of Quixote Corporation, a publicly owned corporation whose stock is traded on the NASDAQ exchange as QUIX. Quixote is a diversified technology company composed of Energy Absorption Systems, Inc. (manufactures highway crash cushions), Stenograph Corporation (manufactures shorthand machines and computer systems for court reporting) and Disc Manufacturing, Inc. We would be pleased to help you with your CD project or answer any questions you may have.
    [Show full text]
  • File System Layout
    File Systems Main Points • File layout • Directory layout • Reliability/durability Named Data in a File System index !le name directory !le number structure storage o"set o"set block Last Time: File System Design Constraints • For small files: – Small blocks for storage efficiency – Files used together should be stored together • For large files: – ConCguous allocaon for sequenCal access – Efficient lookup for random access • May not know at file creaon – Whether file will become small or large File System Design Opons FAT FFS NTFS Index Linked list Tree Tree structure (fixed, asym) (dynamic) granularity block block extent free space FAT array Bitmap Bitmap allocaon (fixed (file) locaon) Locality defragmentaon Block groups Extents + reserve Best fit space defrag MicrosoS File Allocaon Table (FAT) • Linked list index structure – Simple, easy to implement – SCll widely used (e.g., thumb drives) • File table: – Linear map of all blocks on disk – Each file a linked list of blocks FAT MFT Data Blocks 0 1 2 3 !le 9 block 3 4 5 6 7 8 9 !le 9 block 0 10 !le 9 block 1 11 !le 9 block 2 12 !le 12 block 0 13 14 15 16 !le 12 block 1 17 18 !le 9 block 4 19 20 FAT • Pros: – Easy to find free block – Easy to append to a file – Easy to delete a file • Cons: – Small file access is slow – Random access is very slow – Fragmentaon • File blocks for a given file may be scaered • Files in the same directory may be scaered • Problem becomes worse as disk fills Berkeley UNIX FFS (Fast File System) • inode table – Analogous to FAT table • inode – Metadata • File owner, access permissions,
    [Show full text]
  • Comparative Analysis of Distributed and Parallel File Systems' Internal Techniques
    Comparative Analysis of Distributed and Parallel File Systems’ Internal Techniques Viacheslav Dubeyko Content 1 TERMINOLOGY AND ABBREVIATIONS ................................................................................ 4 2 INTRODUCTION......................................................................................................................... 5 3 COMPARATIVE ANALYSIS METHODOLOGY ....................................................................... 5 4 FILE SYSTEM FEATURES CLASSIFICATION ........................................................................ 5 4.1 Distributed File Systems ............................................................................................................................ 6 4.1.1 HDFS ..................................................................................................................................................... 6 4.1.2 GFS (Google File System) ....................................................................................................................... 7 4.1.3 InterMezzo ............................................................................................................................................ 9 4.1.4 CodA .................................................................................................................................................... 10 4.1.5 Ceph.................................................................................................................................................... 12 4.1.6 DDFS ..................................................................................................................................................
    [Show full text]
  • CXFS Customer Presentation
    CXFS Clustered File System from SGI April 1999 R. Kent Koeninger Strategic Technologist, SGI Software [email protected] www.sgi.com File Systems Technology Briefing UNIX (Irix) • Clustered file system features: CXFS Applications CXFS • File System features: XFS XFS XVM FC driver • Volume management: XVM Page 2 Clustered File Systems CXFS Page 3 CXFS — Clustered SAN File System High resiliency and availability Reduced storage costs Scalable high Streamlined performance LAN-free backups Fibre Channel Storage Area Network (SAN) Page 4 CXFS: Clustered XFS • Clustered XFS (CXFS) attributes: – A shareable high-performance XFS file system • Shared among multiple IRIX nodes in a cluster • Near-local file system performance. – Direct data channels between disks and nodes. – A resilient file system • Failure of a node in the cluster does not prevent access to the disks from other nodes – A convenient interface • Users see standard Unix filesystems – Single System View (SSV) – Coherent distributed buffers Page 5 Comparing LANs and SANs LAN LAN: Data path through server (Bottleneck, Single point of failure) SAN: Data path direct to disk (Resilient scalable performance) SAN Page 6 CXFS Client-Server Cluster Technology CXFS Server Node CXFS Client Node Coherent Coherent System System Data Buffers Data Buffers Metadata Token Path Token Metadata Protected CXFS CXFS Shared Protected Server IP-Network Data Client Shared XFS’ Data XFS Log Direct Channels Shared Disks Page 7 Fully Resilient - High Availability CXFS Server Client machines CXFS Client act as redundant backup servers Backup Server-2 CXFS Client CXFS Client Backup Server-1 Backup Server-3 Page 8 CXFS Interface and Performance • Interface is the same as multiple processes reading and writing shared files on an SMP – Same open, read, write, create, delete, lock-range, etc.
    [Show full text]
  • SGI's Complex Data Management Architectures
    SGI® Complex Data Management Strategy and Solutions LaNet Merrill SGI SAN Product Manager Topics –Overview of SGI® Complex Data Management –Architectures and Solutions –SGI Solutions in Action SGI® Delivers Solutions with Unmatched Capabilities and Power SGI is focused on the demanding requirements of technical and creative professionals and extending our technology into heterogeneous environments Hiiigh- Performance Computiiing Advanced Viiisuallliiizatiiion Complllex Data Management Data Explosion - The Problem ‘There are Hiiigh-Ava‘Aiiilllsa bmiiiyllliii tryequiiirements changbea, sIII iiimc ay have to move between DAcS,a NpAabSiiillliiitiiies III and SANDsa.ta wiiillllll alllways Shariiing III don’t want to get lllocked niiine -ed …’ Backu Dead-ends, box upgrades, pbroken appllliiicatiiions and lllots of data HS format changes are NOT M ‘... Anadc cIII edpotanb’lllte ’want to lllose them as my requiiirements for compute, bandwiiidth, and capaciiity change’ Problem Statement: The Data Explosion— What WOULD Solve the Problem? My basiiic, core capa“bIIIfiii lllIIIiii tniiieese sdh Cooulllmdpute or system “My techn“oIIIflll oIII gnye esdh otuolll dc haadnaSgpMet storage movbea wndiiitwh iiidmteh. III shoullld be Habllle to me, noatr cthheiiit eoctthuerre ws paIII yshoullldn’t to jjjust add iiit. Samkue wiiith round” have to woacrry about buying have to w Borry about buyii ng storage capagc iiity” all newiii n equipment and all ll nearw equii pment and Sh Compute cah angiiing my appllliiicatiiions” at Bandwiiidth D y Capaciiity lll iii t biii iii lll a va A gh Hiii DAS NAS SAN SAN/NAS Hybriiid Storage IIInfrastructures SGI® Complex Data Management Strategy High-Performance, Integrated Storage Solutions Performance: Integrating the bandwidth and data needs of servers, visualization and storage providing ultimate bandwidth and capacity.
    [Show full text]