1 / 23

CS 4284 Systems Capstone

CS 4284 Systems Capstone. Disks & File Systems. Godmar Back. Filesystems. Advanced Techniques. Delayed Block Allocation, Preallocation , and Defragmentation. Idea: delay block allocation until write back (eviction time)

rusk
Download Presentation

CS 4284 Systems Capstone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 4284Systems Capstone Disks & File Systems Godmar Back

  2. Filesystems Advanced Techniques CS 4284 Spring 2013

  3. Delayed Block Allocation, Preallocation, and Defragmentation • Idea: delay block allocation until write back (eviction time) • Combine with data structure that simplifies finding continuous sections of free blocks • Increases chances for contiguous physical layout of blocks that are likely to be accessed sequentially • Online defragmentation • Some filesystem reallocate blocks to improve spatial locality • Preallocation • Supports guarantee of contiguous space without actually writing CS 4284 Spring 2013

  4. Avoiding in-place updates • Most traditional designs allocate blocks once and for all (when files is created, grown, etc.) • All subsequent updates go this location (whether it requires seeks or not – makes writes not sequential) • Idea: • Write wherever there’s a free block, write a new version of metadata that points to it – more to write, but sequential (thus faster) • What to do with old data • Can garbage collect and reclaim • Keep around and offer to user as snapshot of past (e.g., NetApp’s .snapshot directory) • Pioneered in LFS (log-structured filesystem), see [Rosenblum 1991] • For RAID, avoids small write problem CS 4284 Spring 2013

  5. Example: COW transactions in ZFS Source: ZFS – The Last Word in Filesystems CS 4284 Spring 2013

  6. End-to-end Data Integrity • Most current file systems assume no undetected bit errors in storage stack • No longer true in practice: disk capacity increases exponentially, error rate does not decrease (1 in 1014 to 1 in 1015 undetected and uncorrected errors) • File systems can do end-2-end checksumming to detect corrupted data • Either only for metadata (ext4) • For all data (ZFS) CS 4284 Spring 2013

  7. Increased Fault Tolerance • Traditional approach: • File system does minimal state replication • Maybe superblock, but not file data or meta data • Relies on underlying layer: RAID mirroring • Single bad block on disk may lead to loss of entire disk • (in RAID case: silent errors may occur, since first READ is believed) • ZFS approach: have file system replicate data and metadata in storage pool • User decides how many copies CS 4284 Spring 2013

  8. Variable Blocksizes • Recall trade-off involving block size • Too small – low data rate, high metadata overhead • Too large – much space lost to internal fragmentation (since many files are small) • Ideally, block size matches size of write requests done to file (“object size”) • No internal fragmentation • No read/modify/write operations • ZFS supports this CS 4284 Spring 2013

  9. Metadata Consistency • Traditional file systems separate designs for metadata (directories and index trees) from designs chosen for metadata consistency • Result: need synchronous writes, logging, or write ordering. • Consistency often retrofitted (e.g., ext2 to ext3) • Cannot make use of atomic updates (which would avoid need for either of these approaches!) • Alternative: design entire filesystem so that atomic updates become possible CS 4284 Spring 2013

  10. ZFS’s Approach Source: ZFS – The Last Word in Filesystems CS 4284 Spring 2013

  11. Other Developments • Built-in encryption and compression • Built-in support for incremental backup • Built-in support for indexing • Explicit support for SSD (solid-state drives) • Support for hybrid drives (or supporting solid state) • E.g. Vista Ready Boost – uses solid state to absorb random writes and reads CS 4284 Spring 2013

  12. Filesystems Linux VFS Volume Managers CS 4284 Spring 2013

  13. Example: Linux VFS Reality: system must support more than one file system at a time Users should not notice a difference unless unavoidable Most systems, Linux included, use an object-oriented approach: VFS-Virtual Filesystem CS 4284 Spring 2013

  14. Example: Linux VFS Interface struct file_operations { struct module *owner; loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t); ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*flush) (struct file *); int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, struct dentry *, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *); ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *); ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void *); ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); int (*check_flags)(int); int (*dir_notify)(struct file *filp, unsigned long arg); int (*flock) (struct file *, int, struct file_lock *); }; CS 4284 Spring 2013

  15. Volume Management Traditionally, disk is exposed as a block device (linear array of blocks abstraction) Refinement: disk partitions = subarray within block array Filesystem sits on partition Problems: Filesystem size limited by disk size Partitions hard to grow & shrink Solution: Introduce another layer – the Volume Manager (aka “Logical Volume Manager”) CS 4284 Spring 2013

  16. Volume Manager Volume Manager separates physical composition of storage devices from logical exposure ext3 /home jfs /opt ext3 /usr filesystems logical volumes LV1 LV2 LV3 VolumeGroup physicalvolumes PV1 PV2 PV3 PV4 CS 4284 Spring 2013

  17. RAID – Redundant Arrays of Inexpensive Disks Idea born around 1988 Original observation: it’s cheaper to buy multiple, small disks than single large expensive disk (SLED) SLEDs don’t exist anymore, but multiple disks arranged as a single disk still useful Can reduce latency by writing/reading in parallel Can increase reliability by exploiting redundancy I in RAID now stands for “independent” disks Several arrangements are known, 7 have “standard numbers” Can be implemented in hardware/software RAID array would appear as single physical volume to LVM CS 4284 Spring 2013

  18. RAID 0 RAID: Striping data across disk Advantage: If disk accesses go to different disks, can read/write in parallel → decrease in latency Disadvantage: Decreased reliability MTTF(Array) = MTTF(Disk)/#disks CS 4284 Spring 2013

  19. RAID 1 RAID 1: Mirroring (all writes go to both disks) Advantages: Redundancy, Reliability – have backup of data Potentially better read performance than single disk – why? About same write performance as single disk Disadvantage: Inefficient storage use CS 4284 Spring 2013

  20. Using XOR for Parity Recall: X^X = 0 X^1 = !X X^0 = X Let’s set: W=X^Y^Z X^(W)=X^(X^Y^Z)=(X^X)^Y^Z=0^(Y^Z)=Y^Z Y^(X^W)=Y^(Y^Z)=0^Z=Z Obtain: Z=X^Y^W (analogously for X, Y) X Y Z W CS 4284 Spring 2013

  21. RAID 4 RAID 4: Striping + Block-level parity Advantage: need only N+1 disks for N-disk capacity & 1 disk redundancy Disadvantage: small writes (less than one stripe) may require 2 reads & 2 writes Read old data, read old parity, write new data, compute & write new parity Parity disk can become bottleneck CS 4284 Spring 2013

  22. RAID 5 RAID 5: Striping + Block-level Distributed Parity Like RAID 4, but avoids parity disk bottleneck Get read latency advantage like RAID 0 Best large read & large write performance Only remaining disadvantage is small writes “small write penalty” CS 4284 Spring 2013

  23. Other RAID Combinations RAID-6: dual parity, code-based, provides additional redundancy (2 disks may fail before data loss) RAID (0+1) and RAID (1+0): Mirroring+striping CS 4284 Spring 2013

More Related