An I/O Simulator for Windows Systems

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

2. 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 PRiSM Lab/ University of Versailles

3. 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 ? PRiSM Lab/ University of Versailles

4. 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 I/O request FastIO File System Driver Storage Device Driver Cache Manager Page miss Storage Device Virtual Memory Manager PRiSM Lab/ University of Versailles

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

6. 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. PRiSM Lab/ University of Versailles

7. 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. PRiSM Lab/ University of Versailles

8. 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. PRiSM Lab/ University of Versailles

9. 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 PRiSM Lab/ University of Versailles

10. One requested block: 3 blocks of 64KB 64KB block loaded by the system process 64KB block loaded by the application process 1 1 1 2 2 2 Windows cache / disk cache • Windows prefetching algorithms: No buffer mode • Read operations: • Sequential mode: loading data sequentially Bn, Bn+1, Bn+2, Bn+3, etc. • Normal mode (default) System process: B1 B2 B3 B4 3 3 3 What are the disk cache reactions? Will it load a part of these data ? The final sequence of request blocks is: B1,1,B1,2, B1,3, B3,1, B2,1, B3,2,B2,2, B3,3,B2,3,B4,1 ,B4,2, .. PRiSM Lab/ University of Versailles

11. Request block Application 64KB block Disk File system cache flush 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 ? PRiSM Lab/ University of Versailles

12. 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 PRiSM Lab/ University of Versailles

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

14. Automatic parameter extraction tool for the simulation I/O sequence strategy defined by the user / real traces Storage architecture to simulate Behavior of the storage system for the specified I/O strategy Developed tools I/O Generator Simulation Tool 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. PRiSM Lab/ University of Versailles

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