DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 17 Disk Management and File Systems

This preview shows page 1-2-24-25 out of 25 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162 Operating Systems and Systems Programming Lecture 17 Disk Management and File SystemsReview: Want Standard Interfaces to DevicesReview: How Does User Deal with Timing?Goals for TodayMain components of Intel Chipset: Pentium 4How does the processor talk to the device?Memory-Mapped Display Controller ExampleTransferring Data To/From ControllerA Kernel I/O StructureAdministriviaDevice DriversLife Cycle of An I/O RequestI/O Device Notifying the OSHard Disk DrivesProperties of a Hard Magnetic DiskDisk I/O PerformanceMagnetic Disk CharacteristicTypical Numbers of a Magnetic DiskDisk PerformanceDisk TradeoffsIntroduction to Queuing TheoryBackground: Use of random distributionsA Little Queuing Theory: Some ResultsA Little Queuing Theory: An ExampleSummaryCS162Operating Systems andSystems ProgrammingLecture 17Disk Management andFile SystemsOctober 29, 2008Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 17.210/29/08 Kubiatowicz CS162 ©UCB Fall 2008Review: Want Standard Interfaces to Devices•Block Devices: e.g. disk drives, tape drives, Cdrom–Access blocks of data–Commands include open(), read(), write(), seek()–Raw I/O or file-system access–Memory-mapped file access possible•Character Devices: e.g. keyboards, mice, serial ports, some USB devices–Single characters at a time–Commands include get(), put()–Libraries layered on top allow line editing•Network Devices: e.g. Ethernet, Wireless, Bluetooth–Different enough from block/character to have own interface–Unix and Windows include socket interface»Separates network protocol from network operation»Includes select() functionality–Usage: pipes, FIFOs, streams, queues, mailboxesLec 17.310/29/08 Kubiatowicz CS162 ©UCB Fall 2008Review: How Does User Deal with Timing?•Blocking Interface: “Wait”–When request data (e.g. read() system call), put process to sleep until data is ready–When write data (e.g. write() system call), put process to sleep until device is ready for data•Non-blocking Interface: “Don’t Wait”–Returns quickly from read or write request with count of bytes successfully transferred–Read may return nothing, write may write nothing•Asynchronous Interface: “Tell Me Later”–When request data, take pointer to user’s buffer, return immediately; later kernel fills buffer and notifies user–When send data, take pointer to user’s buffer, return immediately; later kernel takes data and notifies userLec 17.410/29/08 Kubiatowicz CS162 ©UCB Fall 2008Goals for Today•Finish Discussing I/O Systems–Hardware Access–Device Drivers•Disk Performance–Hardware performance parameters–Queuing Theory•File Systems–Structure, Naming, Directories, and CachingNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from my lecture notes by Kubiatowicz.Lec 17.510/29/08 Kubiatowicz CS162 ©UCB Fall 2008Main components of Intel Chipset: Pentium 4•Northbridge:–Handles memory–Graphics•Southbridge: I/O–PCI bus–Disk controllers–USB controllers–Audio–Serial I/O–Interrupt controller–TimersLec 17.610/29/08 Kubiatowicz CS162 ©UCB Fall 2008DeviceControllerreadwritecontrolstatusAddressableMemoryand/orQueuesRegisters(port 0x20)HardwareControllerMemory MappedRegion: 0x8f008020BusInterfaceHow does the processor talk to the device?•CPU interacts with a Controller–Contains a set of registers that can be read and written–May contain memory for request queues or bit-mapped images •Regardless of the complexity of the connections and buses, processor accesses registers in two ways: –I/O instructions: in/out instructions»Example from the Intel architecture: out 0x21,AL–Memory mapped I/O: load/store instructions»Registers/memory appear in physical address space»I/O accomplished with load and store instructionsAddress+DataInterrupt RequestProcessor Memory BusCPURegularMemoryInterruptControllerBusAdaptorBusAdaptorOther Devicesor BusesLec 17.710/29/08 Kubiatowicz CS162 ©UCB Fall 2008Memory-Mapped Display Controller Example•Memory-Mapped:–Hardware maps control registers and display memory to physical address space»Addresses set by hardware jumpers or programming at boot time–Simply writing to display memory (also called the “frame buffer”) changes image on screen»Addr: 0x8000F000—0x8000FFFF–Writing graphics description to command-queue area »Say enter a set of triangles that describe some scene»Addr: 0x80010000—0x8001FFFF–Writing to the command register may cause on-board graphics hardware to do something»Say render the above scene»Addr: 0x0007F004•Can protect with page tablesDisplayMemory0x8000F0000x80010000Physical AddressSpaceStatus0x0007F000Command0x0007F004GraphicsCommandQueue0x80020000Lec 17.810/29/08 Kubiatowicz CS162 ©UCB Fall 2008Transferring Data To/From Controller•Programmed I/O:–Each byte transferred via processor in/out or load/store–Pro: Simple hardware, easy to program–Con: Consumes processor cycles proportional to data size•Direct Memory Access:–Give controller access to memory bus–Ask it to transfer data to/from memory directly•Sample interaction with DMA controller (from book):Lec 17.910/29/08 Kubiatowicz CS162 ©UCB Fall 2008A Kernel I/O StructureLec 17.1010/29/08 Kubiatowicz CS162 ©UCB Fall 2008Administrivia•Group Evaluations (Both Projects 1 and 2)–These MUST be done: you will get a ZERO on your project score if you don’t fill them out–We will be asking you about them, so make sure you are careful to fill them out honestly•Next Week’s Sections–Fill out a survey form to see how class is going–Give you an opportunity to give feedback•Other things–Group problems? Don’t wait.–Talk to TA/talk to me»Let’s get things fixed!Lec 17.1110/29/08 Kubiatowicz CS162 ©UCB Fall 2008Device Drivers•Device Driver: Device-specific code in the kernel that interacts directly with the device hardware–Supports a standard, internal interface–Same kernel I/O system can interact easily with different device drivers–Special device-specific configuration supported with the ioctl() system call•Device Drivers typically divided into two pieces:–Top half: accessed in call path from system calls»implements a set of standard, cross-device calls like open(), close(), read(), write(), ioctl(),


View Full Document

Berkeley COMPSCI 162 - Lecture 17 Disk Management and File Systems

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 17 Disk Management and File Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 17 Disk Management and File Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 17 Disk Management and File Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?