Storage Systems – Part II

1. INF5070 – Media Server and Distribution Systems: Storage Systems – Part II 25/10 - 2004

2. Overview • Previous lecture: disk mechanics, block sizes, scheduling, block placement • Multiple disks • Managing heterogeneous disks • Prefetching • Memory caching • Multimedia File System Examples

3. Multiple Disks

4. Parallel Access • Disk controllers and busses manage several devices • One can improve total system performance by replacing one large disk with many small accessed in parallel • Several independent heads can read simultaneously(if the other parts of the system can manage the speed) Single disk: Two disks: Note:the single disk might be faster, but as seek time and rotational delay are the dominant factors of total disk access time, the two smaller disks might operate faster together performing seeks in parallel...

5. Client1 Client2 Client3 Client4 Client5 Server Striping • Another reason to use multiple disks is when one disk cannot deliver requested data rate • In such a scenario, one might use several disks for striping: • bandwidth disk: Bdisk • required bandwidth: Bdisplay • Bdisplay > Bdisk • read from n disks in parallel: n Bdisk > Bdisplay • clients are serviced in rounds • Advantages • high data rates • higher transfer rate compared to one disk • Drawbacks • can’t serve multiple clients in parallel • positioning time increases (i.e., reduced efficiency)

6. Client1 Client2 Client3 Server Interleaving (Compound Striping) • Full striping usually not necessarytoday: • faster disks • better compression algorithms • Interleaving lets each client may be serviced by only a set of the available disks • make groups • ”stripe” data in a way such thata consecutive request arrive atnext group (here each disk is a group)

7. X0,1 X0,0 X1,1 X1,0 X2,1 X2,0 X3,0 X3,1 Interleaving (Compound Striping) • Divide traditional striping group into sub-groups, e.g., staggered striping • Advantages • multiple clients can still be served in parallel • more efficient disks operations • potentially shorter response time • Potential drawback/challenge • load balancing (all clients access same group)

8. Redundant Array of Inexpensive Disks • The various RAID levels define different disk organizations to achieve higher performance and more reliability • RAID 0 - striped disk array without fault tolerance (non-redundant) • RAID 1 - mirroring • RAID 2 - memory-style error correcting code (Hamming Code ECC) • RAID 3 - bit-interleaved parity • RAID 4 - block-interleaved parity • RAID 5 - block-interleaved distributed-parity • RAID 6 - independent data disks with two independent distributed parity schemes (P+Q redundancy) • RAID 10 - mirrored striped disk array (level 0) which is mirrored (level 1) • RAID 50 - striped (RAID level 0) array whose segments are RAID level 3 arrays • RAID 0+1 - mirrored array (level 1) whose segments are RAID 0 arrays • …

9. Redundant Array of Inexpensive Disks • RAID is intended ... • ... for general systems • ... to give higher throughput • ... to be fault tolerant • For multimedia systems, some requirements are still missing: • low latency • guaranteed response time • optimizations for linear access to large objects • optimizations for cyclic operations • …

10. Replication • Replication is in traditional disk array systems often used for fault tolerance (and higher performance in the new combined RAID levels) • Replication in multimedia systems is used for • reducing hot spots • increase scalability • higher performance • … • and, fault tolerance is often a side effect  • Replication in multimedia scenarios should • be based on observed load • changed dynamically as popularity changes

11. number of viewers of segment j weighting factor number of replicas of segment i this sum considers the number of future viewers for this segment factor for expected benefit for additional copy Dynamic Segment Replication (DSR) • DSR tries to balance load by dynamically replicating hot data • assumes read only, VoD-like retrieval • predefines a load threshold for when to replicate a segment by examining current and expected load • uses copyback streams • replicate when threshold is reached, but which segment and where?? • tries to find a lightly loaded device, based on future load calculations • not necessarily segment that receives additional requests(another segment may have more requests) • replicates based on payoff factor p (replicate segment x with highest p):

12. Some Challenges Managing Multiple Disks • How large should a stripe group and stripe unit be? • Can one avoid hot sets of disks (load imbalance)? • What and when to replicate? • Heterogeneous disks?

13. Heterogeneous Disks

14. File Placement • A multimedia file might be stored (striped) on multiple disks, but how should one choose on which devices? • storage devices limited by both bandwidth and space • we have hot (frequently viewed) and cold (rarely viewed) files • we may have several heterogeneous storage devices • the objective of a file placement policy is to achieve maximum utilization of both bandwidth and space, and hence, efficient usage of all devices by avoiding load imbalance • must consider expected load and storage requirement • should a file be replicated • expected load may change over time

15. Bandwidth-to-Space Ratio (BSR) – I • BSR attempts to mix hot and cold as well as large and small multimedia objects on heterogeneous devices • don’t optimize placement based on throughput or space only • BSR consider both required storage space and throughput requirement(which is dependent on playout rate and popularity) to achieve a best combined device utilization disk(deviation): disk (deviation): disk(no deviation): media object: wasted space wasted bandwidth space bandwidth may vary according to popularity

16. Bandwidth-to-Space Ratio (BSR) – II • The BSR policy algorithm: • input: space and bandwidth requirements • phase 1: • find a device to place the media object according to BSR • if no device, or stripe of devices, can give sufficient space or bandwidth, then add replicas • phase 2: • find devices for the needed replicas • phase 3: • allocate expected load on replica devices according to BSR of the devices • phase 4: • if not enough resources are available, see if other media objects can delete replicas according to their current workload • all phases may be needed adding a new media object or increasing the workload – for decrease, only the phase 3 (reallocation) in needed • Popular, high data rate movies should be on high bandwidth disks

17. X1ready for display X0ready for display disk 0 X2,0 X1,0 X0,0 disk 1 X2,1 X1,1 X0,1 disk 2 disk 3 Disk Grouping • Disk grouping is a technique to “stripe” (or fragment) data over heterogeneous disks • groups heterogeneous physical disks to homogeneous logical disks • the amount of data on each disk (fragments) is determined so that the service time (based on worst-case seeks) is equal for all physical disks in a logical disk • blocks for an object are placed (and read) on logical disks in a round-robin manner – all disks in a group is activated simultaneously logical disk 0 X0,0 X2,0 X0 X2 X0,1 X2,1 logical disk 1 X1,0 X3,0 X1 X3 X1,1 X3,1

18. X0,1ready for display X1,0ready for display X0,0ready for display X2,0ready for display disk 0 disk 1 disk 2 disk 3 Staggered Disk Grouping • Staggered disk grouping is a variant of disk grouping minimizing memory requirement • reading and playing out differently • not all fragments of a logical block is needed at the same time • first (and largest) fragment on most powerful disk, etc. • read sequentially (must not buffer later segments for a long time) • start display when largest fragment is read logical disk 0 X0,0 X2,0 X0 X2 X2,0 X0,0 X2,1 X0,1 X0,1 X2,1 logical disk 1 X1,0 X3,0 X1 X3 X1,0 X1,1 X1,1 X3,1

19. logical disk 0 Xready for display disk 0 logical disk 1 logical disk 2 disk 1 logical disk 3 disk 2 logical disk 4 X1 X3 X0 X4 X2 disk 3 Disk Merging • Disk merging forms logical disks from capacity fragments of a physical disk • all logical disks are homogeneous • supports an arbitrary mix of heterogeneous disks (grouping needs equal groups) • starts by choosing how many logical disks the slowest device shall support (e.g., 1 for disk 1 and 3) and calculates the corresponding number of more powerful devices (e.g., 1.5 for disk 0 and 2 if these disks are 1.5 times better) • most powerful: most flexible (arbitrary mix of devices) and can be adapted to zoned disks (each zone considered as a disk) X0 X0 X2,0 X1 X1 X2 X3 X2,1 X3 X4 X4

20. Prefetching and Buffering

21. Prefetching • If we can predict the access pattern, one might speed up performance using prefetching • a video playout is often linear  easy to predict access pattern • eases disk scheduling • read larger amounts of data per request • data in memory when requested – reducing page faults • One simple (and efficient) way of doing prefetching is read-ahead: • read more than the requested block into memory • serve next read requests from buffer cache • Another way of doing prefetching is double (multiple) buffering: • read data into first buffer • process data in first buffer and at the same time read data into second buffer • process data in second buffer and at the same time read data into first buffer • etc.

22. Multiple Buffering • Example:have a file with block sequence B1, B2, ...our program processes data sequentially, i.e., B1, B2, ... • single buffer solution: • read B1  buffer • process data in buffer • read B2  buffer • process data in buffer • ... • if P = time to process/block R = time to read in 1 block n = # blockssingle buffer operation time = n (P+R) process data memory: disk:

23. Multiple Buffering • double buffer solution: • read B1  buffer1 • process data in buffer1, read B2  buffer2 • process data in buffer2, read B3  buffer1 • process data in buffer1, read B4  buffer2 • ... • if P = time to process/block R = time to read in 1 block n = # blocksif P  R double buffer operation time = R + nP • if P < R, we can try to add buffers (n - buffering) process data process data memory: disk:

24. Memory Caching

25. application file system communication system disk network card I/O controller hub memory controller hub Data Path (Intel Hub Architecture) Pentium 4 Processor registers cache(s) file system RDRAM communication system RDRAM application RDRAM RDRAM network card PCI slots PCI slots disk PCI slots

26. caching possible Memory Caching • How do we manage a cache? • how much memory to use? • how much data to prefetch? • which data item to replace? • … application cache file system communication system expensive disk network card

27. Is Caching Useful in a Multimedia Scenario? • High rate data may need lots of memory for caching… • Tradeoff: amount of memory, algorithms complexity, gain, … • Cache only frequently used data – how?(e.g., first (small) parts of a broadcast partitioning scheme, allow “top-ten” only, …) Maximum amount of memory (totally) that a Dell Server can manage in 2004 – and all is NOT used for caching

28. Need For Special “Multimedia Algorithms” ? In this case, LRU replaces the next needed frame. So the answer is in many cases YES… • Most existing systems use an LRU-variant • keep a sorted list • replace first in list • insert new data elements at the end • if a data element is re-accessed (e.g., new client or rewind), move back to the end of the list • Extreme example – video frame playout: shortest time since access longest time since access LRU buffer play video (7 frames): 3 4 1 2 7 5 6 1 7 2 3 4 5 6 rewind and restart playout at1: 2 1 3 4 5 6 7 playout2: 3 2 4 5 6 7 1 playout3: 4 3 5 6 7 1 2 playout4:

29. “Classification” of Mechanisms • Block-level caching consider (possibly unrelated) set of blocks • each data element is viewed upon as an independent item • usually used in “traditional” systems • e.g., FIFO, LRU, CLOCK, … • multimedia (video) approaches: • Least/Most Relevant for Presentation (L/MRP) • … • Stream-dependent caching consider a stream object as a whole • related data elements are treated in the same way • research prototypes in multimedia systems • e.g., • BASIC • DISTANCE • Interval Caching (IC) • Generalized Interval Caching (GIC) • Split and Merge (SAM) • SHR

30. Buffer request request Least/Most Relevant for Presentation (L/MRP) [Moser et al. 95] • L/MRP is a buffer management mechanism for a single interactive, continuous data stream • adaptable to individual multimedia applications • preloads units most relevant for presentation from disk • replaces units least relevant for presentation • client pull based architecture Homogeneous stream e.g., MJPEG video Continuous Presentation Units (COPU) e.g., MJPEG video frames Server Client

31. referenced history skipped X X X current presentation point relevance value 1.0 16 18 0.8 20 0.6 22 0.4 24 0.2 26 0 COPU number 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Least/Most Relevant for Presentation (L/MRP) [Moser et al. 95] • Relevance values are calculated with respect to current playout of the multimedia stream • presentation point (current position in file) • mode / speed (forward, backward, FF, FB, jump) • relevance functions are configurable COPUs – continuous object presentation units playback direction 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 18 17 16 15 19 14 20 21 13 22 12 23 11 10 24 25 26

32. global relevance value loaded frames current presentation point S2 current presentation point S1 Bookmark-Set Least/Most Relevant for Presentation (L/MRP) [Moser et al. 95] • Global relevance value • each COPU can have more than one relevance value • bookmark sets (known interaction points) • several viewers (clients) of the same • = maximumrelevance for each COPU Relevance 1 0 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... ... Referenced-Set History-Set

33. Least/Most Relevant for Presentation (L/MRP) • L/MRP … • … gives “few” disk accesses (compared to other schemes) • … supports interactivity • … supports prefetching • … targeted for single streams (users) • … expensive (!) to execute (calculate relevance values for all COPUs each round) • Variations: • Q-L/MRP – extends L/MRP with multiple streams and changes prefetching mechanism (reduces overhead) [Halvorsen et. al. 98] • MPEG-L/MRP – gives different relevance values for different MPEG frames [Boll et. all. 00]

34. S33 S34 S32 S11 S31 S11 S12 S12 S11 S13 S21 S22 Video clip 1 Video clip 1 Video clip 1 Video clip 3 Video clip 2 I12 I11 I21 I33 I32 I31 Interval Caching (IC) • Interval caching (IC) is a caching strategy for streaming servers • caches data between requests for same video stream – based on playout intervals between requests • following requests are thus served from the cache filled by preceding stream • up to stream to decide what to do with allocated buffer • sort intervals on length, buffer requirement is data size of interval • to maximize cache hit ratio (minimize disk accesses) the shortest intervals are cached first : I32 I33 I12 I31 I11 I21

35. S12 S22 S21 S11 Video clip 2 I21 Generalized Interval Caching (GIC) • Interval caching (IC) does not work for short clips • a frequently accessed short clip will not be cached • GIC generalizes the IC strategy • manages intervals for long video objects as IC • short intervals extend the interval definition • keep track of a finished stream for a while after its termination • define the interval for short stream as the length between the new stream and the position of the old stream if it had been a longer video object • the cache requirement is, however, only the real requirement • cache the shortest intervals as in IC S11 Video clip 1 I11 C11

36. Generalized Interval Caching (GIC) • Open function: form if possible new interval with previous stream; if (NO) {exit} /* don’t cache */ compute interval size and cache requirement; reorder interval list; /* smallest first */ if (not already in a cached interval) { if (space available) {cache interval} else if (larger cached intervals exist and sufficient memory can be released) { release memory from larger intervals; cache new interval; } } • Close function if (not following another stream) {exit} /* not served from cache */ delete interval with preceding stream; free memory; if (next interval can be cached in released memory) { cache next interval }

37. global relevance values wasted buffering loaded page frames movie X S3 S1 S2 S4 S5 4 streams from disk, 1 from cache 4 streams from disk, 1 from cache 2 streams from disk, 3 from cache LRU vs. L/MRP vs. IC Caching • What kind of caching strategy is best (VoD streaming)? • caching effect I3 I1 I2 I4 Memory (L/MRP): Memory (IC): Memory (LRU):

38. IC LRU L/MRP for each I/O request reorder LRU chain for each I/O request for each COPU RV = 0 for each stream tmp = r(COPU, p, mode) RV = max( RV, tmp) for each block consumed if last part of interval release memory element LRU vs. L/MRP vs. IC Caching • What kind of caching strategy is best (VoD streaming)? • CPU requirement

39. Multimedia File Systems

40. Multimedia File Systems • Many examples of storage systems • integrate several subcomponents (e.g., scheduling, placement, caching, admission control, …) • often labeled differently: file system, file server, storage server, … accessed through typical file system abstractions • need to address multimedia applications distinguishing features: • soft real-time constraints (low delay, synchronization, jitter) • high data volumes (storage and bandwidth)

41. Classification • General file systems: “support” for all applicationse.g.: file allocation table (FAT), windows NT file system (NTFS), second/third extended file system (Ext2/3), journaling file system (JFS), Reiser, fast file system (FFS) • Multimedia file systems: address multimedia requirements • general file systems with multimedia supporte.g.: XFS, Minorca • exclusively streaminge.g.: Video file server, embedded real-time file system (ERTFS), Shark, Everest, continuous media file system (CMFS), Tiger Shark • several application classese.g.: Fellini, Symphony, (MARS & APEX schedulers) • High-performance file systems: primarily for large data operations in short timee.g.: general parallel file system (GPFS), clustered XFS (CXFS), Frangipani, global file system (GFS), parallel portable file system (PPFS), Examplar, extensible file system (ELFS)

42. Fellini Storage System • Fellini (now CineBlitz)… • supports both real-time (with guarantees) and non-real-time by assigning resources for both classes • SGI (IRIX Unix), Sun (Solaris), PC (WinNT & Win95) • Admission control • deterministic (worst-case) to make hard guarantees • services streams in rounds • used (and available) disk BW is calculated using • worst-case seek, rotational delay and settle (servicing latency) • transfer rate of inner track • total disk time = 2 x seek + Σ[blocksi x (rotation delay + settle + transfer)] • used (and available) buffer space is calculated using • buffer requirement per stream = 2 x rate x service round • a new client is admitted if enough free disk BW and buffer space (additionally Fellini checks network BW) • new real-time clients are admitted first

43. Fellini Storage System • Cache manager • pages are pinned (fixing) using a reference counter • replacement in three steps • search free list • search current buffer list (CBL) for the unused, LRU file • search in-use CBLs and assign priorities to replaceable buffers (not pinned) according to reference distance (depending on rate, direction) • sort using Quicksort • replace buffer with highest weight • allocation of free blocks at beginning of each round

44. Fellini Storage System • Storage manager • maintains free list with grouping contiguous blocks  store blocks contiguously • uses C-SCAN disk scheduling • striping is used to distribute and increase total load, and add fault-tolerance (parity data) • simple flat file system • Application interface • real-time: • begin_stream (filename, mode, flags, rate) • retrieve_stream (id, bytes) • store_stream (id, bytes) • seek_stream (id, bytes, whence) • close_stream(id) • non-real-time: more or less as in other file systems, except that when opening one has an admittance check

45. Symphony File System • Symphony • an (integrated) file system supporting several heterogeneous data types (implemented in Solaris) • allows several subsystems have coexisting policies • two layer architecture • data type independent layer performing core file system functionality (e.g., disk scheduling, buffer management, block management, …) • data type dependent layer implementing multiple data type specific policies optimized for that specific data type

46. Symphony File System: Independent Layer • Disk subsystem • service manager: Cello disk scheduling • storage manager: block management (different sizes, placement, …) • fault tolerance layer: RAID-5 like striping, but larger parity blocks • Buffer subsystem • multiple data type specific caching policies can coexist • two buffer pools: used (cached) and unused • used is further partitioned among the various caching policies • Resource manager • provide guarantees through reservation • QoS negotiation • admission control: deterministic (worst-case) & statistical (probabilistic)

47. Symphony File System: Type Specific Layer • Layer where different modules may use different underlying policies or mechanisms (only two implemented!?) • Video module • targeted for video compressed using a variety of schemes • placement: • fixed & variable sized blocks • large arrays are divided into sub-arrays • contiguous block allocation • disk scheduling: • server push uses periodic real-time • client pull uses aperiodic real-time • caching: uses interval caching (IC) • media type specific metadata added • Text module: mechanisms as in traditional Unix systems • inodes, fixed block size, LRU caching, …

48. The End:Summary

49. Summary • Much work has been performed to optimize disks performance • For multimedia streams, ... • time-aware scheduling is important • use large block sizes or read many contiguous blocks • prefetch data from disk to memory to have a hiccup free playout • striping might not be necessary on new disks (at least not on all disks) • replication on multiple disks can offload a hot spot of disks • memory caching can save disk I/Os, but it might not be worth the effort • ... • BUT, new disks are “smart”, we cannot fully control the device • Many existing file systems with various multimedia support

50. Some References • Advanced Computer & Network Corporation: “RAID.edu”, http://www.raid.com/04_00.html, 2002 • Boll, S., Heinlein, C., Klas, W., Wandel, J.: “MPEG-L/MRP: Adaptive Streaming of MPEG Videos for Interactive Internet Applications”, Proceedings of the 6th International Workshop on Multimedia Information System (MIS’00), Chicago, USA, October 2000, pp. 104 - 113 • Halvorsen, P., Goebel, V., Plagemann, T.: “Q-L/MRP: A Buffer Management Mechanism for QoS Support in a Multimedia DBMS”, Proceedings of 1998 IEEE International Workshop on Multimedia Database Management Systems (IW-MMDBMS'98), Dayton, Ohio, USA, August 1998, pp. 162 – 171 • Halvorsen, P., Griwodz, C., Goebel, V., Lund, K., Plagemann, T., Walpole, J.: “Storage System Support for Continuous-Media Applications” (part 1 & 2), DSonline, Vol. 5, No. 1 & 2, January/February 2004 • C. Martin, P.S. Narayan, B. Ozden, R. Rastogi, and A. Silberschatz, ``The Fellini Multimedia Storage System,'' Journal of Digital Libraries , 1997, see also http://www.bell-labs.com/project/fellini/ • Moser, F., Kraiss, A., Klas, W.: “L/MRP: a Buffer Management Strategy for Interactive Continuous Data Flows in a Multimedia DBMS”, Proceedings of the 21th VLDB Conference, Zurich, Switzerland, 1995 • Plagemann, T., Goebel, V., Halvorsen, P., Anshus, O.: “Operating System Support for Multimedia Systems”, Computer Communications, Vol. 23, No. 3, February 2000, pp. 267-289 • Sitaram, D., Dan, A.: “Multimedia Servers – Applications, Environments, and Design”, Morgan Kaufmann Publishers, 2000 • Zimmermann, R., Ghandeharizadeh, S.: “Continuous Display using Heterogeneous Disk-Subsystems”, Proceedings of the 5th ACM International Multimedia Conference, Seattle, WA, November 1997