1. An I/O Simulator for Windows Systems Jalil Boukhobza, Claude Timsit jalil.boukhobza@prism.uvsq.fr 27/10/2004 Versailles Saint Quentin University laboratory

2. PRiSM Lab/ University of Versailles2 27/10/2004 Outline Introduction Overview of the Windows I/O system architecture Description of the simulator’s architecture (WinIOSim) What’s new in WinIOSim? Inputs / Outputs of the simulator Validation of WinIOSim Summary

3. PRiSM Lab/ University of Versailles3 27/10/2004 Introduction Windows I/O system is poorly studied CreateFile(): many file access modes different caching algorithms big performance fluctuations for a given workload. Disk subsystems built independently from OS  Interaction with the OS are not easily predictable What is the performance of a given workload on a given system architecture for a defined I/O strategy on Windows systems ?

4. PRiSM Lab/ University of Versailles4 27/10/2004 Overview of the Windows I/O system architecture Different file access modes in the CreateFile() function:  Without using the file system cache: no buffer mode (FILE_FLAG_NO_BUFFERING)  Using the file system cache: sequential, normal, write through modes. FILE_FLAG_SEQUENTIAL_SCAN, FILE_ATTRIBUTE_NORMAL, FILE_FLAG_WRITE_THROUGH Storage Device I/O request FastIO Page miss Cache Manager File System Driver Storage Device Driver Virtual Memory Manager

5. PRiSM Lab/ University of Versailles5 27/10/2004 Description of the WinIOSim architecture (OMNET++) I/O generator 1 Application process System process Process memory File system cache I/O scheduler Disk buffer DiskDisk Storage device subsystem modules I/O generator 2 I/O generator n Operating system modules Application modules

6. PRiSM Lab/ University of Versailles6 27/10/2004 The WinIOSim modules I/O generators: flexible workload generator  Request types, sizes, numbers, inter arrival times Access modes, requested addresses, etc.  Different possible distributions for each parameter (poisson, uniform, exponential, etc.) thanks to OMNET++  Possible to plug real traces  Implemented request criticality (synchronous and asynchronous requests) The process memory and file system cache modules: simulating the data copy operations, updating policies, etc.

7. PRiSM Lab/ University of Versailles7 27/10/2004 The WinIOSim modules (2) The application and system processes:  Request flow control  Request grouping and splitting  File system cache prefetching algorithms, lazy write and write through algorithms depending on access modes  Both communicate to issue the final request sequence (as seen by the disk) The different buses: simulating bus throughput, delays, sharing.

8. PRiSM Lab/ University of Versailles8 27/10/2004 The WinIOSim modules (3) IO scheduler module: controls the flow of requests to the disk subsystem  Queuing system: FIFO, SCAN, LOOK, SSPF, C-LOOK, C- SCAN, etc. The disk module: very detailed model  Mapping, zoning, spare area, number of platters, seek times, rotational speed, head switching times, track and cylinder skew, etc. The disk cache module:  Segmentation, read ahead algorithms, lazy write and write through algorithms, cache updating policies, etc.

9. PRiSM Lab/ University of Versailles9 27/10/2004 What’s new in WinIOSim? Implementation of Windows specific cache algorithms depending on access modes identified by reverse engineering work  Specific sequences of data issued by the system and application process for each access mode Disk subsystem reactions to these algorithms  Specific reactions for specific sequences depending on the disk

10. PRiSM Lab/ University of Versailles10 27/10/2004 Windows cache / disk cache Windows prefetching algorithms: No buffer mode  Read operations: Sequential mode: loading data sequentially B n, B n+1, B n+2, B n+3, etc. Normal mode (default) System process: One requested block: 3 blocks of 64KB 64KB block loaded by the system process 64KB block loaded by the application process What are the disk cache reactions? Will it load a part of these data ? B1B1 B2B2 B3B3 B4B4 The final sequence of request blocks is: B 1,1, B 1,2, B 1,3, B 3,1, B 2,1, B 3,2,B 2,2, B 3,3, B 2,3, B 4,1, B 4,2,.. 123123123

11. PRiSM Lab/ University of Versailles11 27/10/2004 Windows cache / disk cache (2)  Write operations: Sequential and normal modes : for one request some blocks are flushed on the disk and the others on the file system cache (later on flushed on the disk). Write through mode  Each written block -> file system cache -> disk cache -> disk + modification of a system file on the disk -> acknowledge. How will the disk react to those sequences of blocks to write ? 64KB block Application File system cache Disk flush Request block

12. PRiSM Lab/ University of Versailles12 27/10/2004 Inputs / Outputs of the simulator The inputs  I/O generator configuration Modeled by the user Real I/O traces  The simulated architecture definition If existing:  Obtained from manufacturers (rarely complete)  Obtained using the WIOTest parameter extraction tool we developed. The outputs  Response times and throughputs (2 main metrics for I/Os)  The different states of the modules at each stage of the simulation

13. PRiSM Lab/ University of Versailles13 27/10/2004 Validation of WinIOSim Response time measures / simulations of file read/write operation on a sequential file with different access modes. Less than 4% variation

14. PRiSM Lab/ University of Versailles14 27/10/2004 Summary Efficient tool for Windows I/O system simulation. Very accurate and flexible simulations of the whole Windows IO system: from application to disk. Simulation of the interactions between the modules for example file system cache and disk cache. Unitary response time validation. Storage architecture to simulate I/O sequence strategy defined by the user / real traces I/O Generator Simulation Tool Behavior of the storage system for the specified I/O strategy Automatic parameter extraction tool for the simulation Developed tools

15. PRiSM Lab/ University of Versailles15 27/10/2004 Thank you ! Questions ? www.prism.uvsq.fr/users/jboukh jalil.boukhobza@prism.uvsq.fr