DOC PREVIEW
Berkeley COMPSCI 162 - Disk Management and File Systems

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 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 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162Operating Systems andSystems ProgrammingLecture 17Disk Management andFile SystemsOctober 28, 2009Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 17.210/28/09Kubiatowicz CS162 ©UCB Fall 2009Review: 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/28/09Kubiatowicz CS162 ©UCB Fall 2009Review: 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 user Lec 17.410/28/09Kubiatowicz CS162 ©UCB Fall 2009Goals 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/28/09Kubiatowicz CS162 ©UCB Fall 2009Main 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/28/09Kubiatowicz CS162 ©UCB Fall 2009DeviceControllerreadwritecontrolstatusAddressableMemoryand/orQueuesRegisters(port 0x20)HardwareControllerMemory MappedRegion: 0x8f008020BusInterfaceHow does the processor talk to the device?• CPU interacts with a Controller– Contains a set of registersthat 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/28/09Kubiatowicz CS162 ©UCB Fall 2009Memory-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/28/09Kubiatowicz CS162 ©UCB Fall 2009Transferring 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/28/09Kubiatowicz CS162 ©UCB Fall 2009A Kernel I/O StructureLec 17.1010/28/09Kubiatowicz CS162 ©UCB Fall 2009Administrivia• Midterm I results:– Mean: 65.6, STD: 15.0– Min: 33.5, Max: 98.0• Glookup Grades:– Will try to update sooner• Group Evaluations (Both Projects 1 and 2)– These MUST be done: you will get ZERO if you don’t fill them out– Fill them out honestly (you will be potentially asked about them)• 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!0246810121416182035 40 45 50 55 60 65 70 75 80 85 90Lec 17.1110/28/09Kubiatowicz CS162 ©UCB Fall 2009Device 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(),strategy()» This is the kernel’s interface to the device driver» Top half will startI/O to device, may put thread to sleep until finished– Bottom half: run as interrupt routine» Gets input or transfers next block of output» May wake sleeping threads if I/O now completeLec 17.1210/28/09Kubiatowicz CS162 ©UCB Fall 2009Life Cycle of An I/O RequestDevice DriverTop HalfDevice DriverBottom HalfDeviceHardwareKernel I/OSubsystemUserProgramLec 17.1310/28/09Kubiatowicz CS162 ©UCB Fall 2009I/O Device Notifying the OS• The OS needs to know when:– The I/O


View Full Document

Berkeley COMPSCI 162 - 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 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 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 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?