CS370: System Architecture & Software [Fall 2014] Dept. Of Computer Science, Colorado State University

Transcription

1 CS 370: SYSTEM ARCHITECTURE & SOFTWARE [MASS STORAGE] Frequently asked questions from the previous class survey Shrideep Pallickara Computer Science Colorado State University L29.1 L29.2 Topics covered in this lecture Recovery in File Systems RAID Disk Management RECOVERY Instructor: SHRIDEEP PALLICKARA L29.3 L29.4 Coping with system failures File system structures are maintained on disk and in memory Operations result in structural changes to the file system on disk Changes may be interrupted by a crash System failures should not result in Data Loss Inconsistencies among data structures Sources of inconsistency OS cache to optimize performance If cached changes do not reach disk n Corruption Bugs may also corrupt a file system File system implementation Disk controllers Applications L29.5 L29.6 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.1

2 Inconsistency example: File creation Directory structure is modified, inode is set aside, etc Free inode count may indicate that an inode has been allocated But the directory structure may not point to it Consistency checking: Approaches (I) Scan all metadata of file system Confirm or deny consistency Time consuming (II) Record state within file system metadata At start of metadata change the status bit set n Metadata is in flux If metadata updates complete successfully n Clear the status bit If bit is set: a consistency checker is run L29.7 L29.8 Consistency checker compares structure with data on disk and tries to fix inconsistencies Allocation & free space management algorithms dictate efficiency and success Linked list allocation Link exists from block to block File can be recreated Indexed allocation Loss of inode entry is disastrous n File blocks have no knowledge of each other Some issues with consistency checking Inconsistency may be irreparable Inability to recover structures Loss of files (possibly entire directories) Can require human intervention for conflict resolution Unavailable until this is performed Can be very time consuming Can take up to several hours L29.9 L29.10 Applying log-based recovery techniques to file system METADATA UPDATES LOG-STRUCTURED FILE SYSTEMS All metadata changes are written sequentially to a log Changes written to log are considered committed System call can return Log entries are replayed across actual file system structures L29.11 L29.12 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.2

3 Some things about the log file Implemented as a circular buffer When action is completed n Buffer entry is removed and pointer is advanced Log location Separate section of the file system Perhaps on a separate disk n Efficiency After a system crash the log is inspected Log will contain zero or more transactions If there are non-zero transactions Not completed but committed by the OS n Must be completed Aborted transaction: Not committed before crash n Undone Recovery is much more targeted L29.13 L29.14 Benefits of using logging for disk metadata updates Costly synchronous random metadata writes Become (less expensive) synchronous, sequential writes to the logging area Changes in log are replayed asynchronously to appropriate disk structures Random writes Updates are much faster than when they are applied directly to on-disk structures Other approaches Never overwrite blocks with new data All data and metadata changes in new blocks When transaction completes Structures updated to point to the new block Old blocks can be reused If NOT, a snapshot preserves view before the update ZFS checksums all data and metadata blocks L29.15 L29.16 RAID involves using large number of disks in parallel Improves rate at which data be can read/written Increases reliability of storage Redundant information can be stored on multiple disks Failure of 1 disk should not result in loss of data Independent Redundant Array of Inexpensive Disks RAID STRUCTURE L29.17 L29.18 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.3

4 RAID levels Standardized by the Storage Networking Industry Association (SNIA) In the Common RAID Disk Drive Format (DDF) standard Originally there were 5 levels There are other nested levels Reliability through redundancy Store information that is not normally needed Can be used in the event of disk failure Rebuild lost information Simplest approach: Mirroring Duplicate every disk Data lost only if 2 nd disk fails BEFORE 1 st one is replaced Watch for: Correlated failures L29.19 L29.20 RAID parallelism Stripe data across disks Objectives 1 Increase throughput 2 Reduce response times of large accesses RAID Parallelism: Stripe data across disks Bit level striping Split bits of each byte across multiple disks 8 disks: Bit i of each byte written to disk i Bit 3 written to disk 3 Array of 8 disks treated as a single disk 8 times the access rate Every disk participates in every read/write L29.21 L29.22 RAID Parallelism: Block-level striping Blocks of a file are striped across multiple disks When there are n disks Block i of the file written to Disk: (i mod n) + 1 n 4 disks: Block 9 of file goes to disk 2 n 4 disks: Block 8 of file goes to disk 1 RAID levels Striping improves transfer rates BUT not reliability Disk striping usually combined with parity Different schemes classified according to levels RAID levels L29.23 L29.24 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.4

5 RAID 0: Stripe blocks without redundancy RAID 1: Disk mirroring C C C C No mirroring No parity Each disk is mirrored L29.25 L29.26 RAID 2: Memory style error correcting code Parity bit records number of 1 bits in byte Even: parity 0 Odd: parity 1 Use to detect single-bit errors Error correcting schemes 2 or more extra bits to recover from single-bit errors RAID 2: Error Correcting Codes P P P Error correction bits If one disk fails: Remaining bits of the byte + error correction bits Read from other disks Reconstruct damaged data L29.27 L29.28 RAID 3: Single parity bit used for error correction We can identify damaged sector Figure out if any bit in sector is 0 or 1 Compute parity of corresponding bits from other sectors n If parity of remaining bits == stored parity Missing bit = 0 n Otherwise, missing bit = 1 RAID 3: Single parity bit used for error correction Issues P Error correction bits Fewer I/Os per-second since every disk participates in every I/O Overheads for computing parity bits L29.29 L29.30 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.5

6 RAID-4 Block interleaved parity Block-level striping Block read accesses only one disk Data transfer rate slower for each access Multiple reads proceed in parallel n Higher overall I/O rate Parity block on a separate disk RAID 4: Block interleaved parity If one disk fails P Parity block Parity block used with corresponding blocks Restore blocks of failed disk L29.31 L29.32 RAID-5 Block interleaved distributed parity RAID 5: Block interleaved distributed parity Spread data and parity among all N+1 disks Avoid overuse of single parity disk Parity block does not store parity for blocks on the same disk L29.33 L29.34 RAID-6 RAID-6 Store extra redundant information Guard against multiple disk failures Error correcting codes are used Reed-Solomon codes 2-bits of redundant data For every 4-bits of data L29.35 L29.36 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.6

7 In the computer science department RAID 1 To mirror the root disks of the servers RAID 5 For all the "no_back_up" partitions RAID 6 For all data disks DISK MANAGEMENT Instructor: SHRIDEEP PALLICKARA L29.37 L29.38 Disk Formatting needs to be done before a disk can store data Divide disk drive into sectors Read/written to by disk controller Low-level formatting Special data structure for each sector Header n Sector number Data area (usually, 512 bytes) Trailer n Error correcting code Disk controller allows you to specify how to low-level format a disk Specify data space between header and trailer 256, 512, 1024 bytes Larger sector data space More space for user data Smaller space for header/trailer L29.39 L29.40 Sectors and ECC When a controller writes a sector of data ECC is updated with value calculated based on data stored When a controller reads a sector of data ECC is recomputed Compared with the stored value Mismatch n Sector data is corrupted Corrupted sectors and the ECC If only a few bits have been corrupted ECC can identify which bits changed What their values should be Recoverable soft error L29.41 L29.42 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.7

8 OS also needs to record its own data structures to the disk Partition disk into 2 or more groups of cylinders E.g one holds OS, the other holds user files Logical formatting Creation of a file system Initial data structures stored onto disk Sometimes, group blocks into clusters n For efficiency of reads and writes Boot block Tiny bootstrap loader brings the full bootstrap program to disk Full bootstrap program stored in boot blocks Fixed location of disk Windows 2000 places its boot code on 1 st sector of hard disk Once system identifies boot partition Reads 1 st sector of disk and proceeds from there L29.43 L29.44 Managing bad blocks Manually during logical formatting Update allocation structure Tell allocation routines not to use the bad block Disk controller maintains list of bad blocks Updated over the life of the disk MANAGING BAD BLOCKS L29.45 L29.46 Setting aside spare sectors to cope with bad blocks also helps Replace bad sector logically with another one Redirection could invalidate scheduling decisions Set aside spare sectors in each cylinder Sector slipping Remap sectors by moving them down one spot SWAP SPACE MANAGEMENT Instructor: SHRIDEEP PALLICKARA L29.47 L29.48 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.8

9 Virtual memory uses the disk space as an extension of main memory Using swap space decreases system performance Main objective of swap space Provide best possible throughput for the virtual memory system Swap space location Carved out of the normal file system Navigating directory and allocation data structures n Time consuming n Could result in additional disk accesses Use a raw partition Separate swap-space manager (De)allocate blocks from the raw partition L29.49 L29.50 Using the raw partition Swap space accessed more frequently than the file system Algorithms are optimized for speed not efficiency Internal fragmentation may be higher BUT swap space data have shorter life spans n Acceptable trade-off The contents of this slide-set are based on the following references Avi Silberschatz, Peter Galvin, Greg Gagne. Operating Systems Concepts, 9 th edition. John Wiley & Sons, Inc. ISBN-13: [Chapter 10, 11] Andrew S Tanenbaum and Herbet Bos. Modern Operating Systems. 4 th Edition, Prentice Hall. ISBN: X/ [Chapter 5] L29.51 L29.52 SLIDES CREATED BY: SHRIDEEP PALLICKARA L29.9