File System & Device Drive FS Implementation. File System Structure. Layered File System. File System Layers. I/O subsystem & Device Drivers

Transcription

1 CS341: Operating System File System & Device Drive FS Implementation File system Implementation I/O subsystem & Device Drivers Lect40: 13 th Nov 2014 Dr. A. Sahu Dept of Comp. Sc. & Engg. Indian Institute of Technology Guwahati File System Structure File structure Logical storage unit Collection of related information File systemresides on (disks) Provided Provideduser interface to storage, mapping logical to physical Provides efficient and convenient access to disk by allowing data to be stored, located retrieved easily File System Structure Disk provides in place rewrite and random access I/O transfers performed in blocksof sectors (usually 512 bytes) File Control block storage structure consisting of information about a file Inode Device drivercontrols the physical device File system organized into layers Layered File System Application Program Logical File System File Organization Module Basic File System I/O Control Devices File System Layers Device drivers Manage I/O devices at the I/O control layer Given commands like read drive1, cylinder 72, track 2, sector 10, into memory location 1060 Outputs low level hardware specific commands to hardware controller APP Logical FS F Org.Mod Basic FS I/O Control Devices 1

2 Basic file system File System Layers Given command like retrieve block 123 translates to device driver Also manages memory buffers and caches Allocation, freeing, replacement Buffers hold data in transit Caches hold frequently used data APP Logical FS F Org.Mod Basic FS I/O Control Devices File System Layers File organization module understands files, logical address, and physical blocks Translates logical block # to physical block # Manages free space, disk allocation APP Logical FS F Org.Mod Basic FS I/O Control Devices File System Layers Logical file system manages metadata information Translates file name into file number, file handle, location by maintaining file control blocks (inodesin UNIX) Directory management Protection APP Logical FS F Org.Mod Basic FS I/O Control Devices File System Layers (Cont.) Layering Useful for reducing complexity & redundancy, But adds overhead : decrease performance Translates File name into File number, file handle, location By maintaining file control blocks (inodes) Logical layers can be implemented by any coding method according to OS designer APP Logical FS F Org.Mod Basic FS I/O Control Devices File System Layers (Cont.) Many file systems, sometimes many within an operating system, Each with its own format CD ROM is ISO 9660; Unix has UFS, FFS; Windows has FAT, FAT32, NTFS as well as Floppy, CD, DVD Blu ray, Linux has more than 40 types, with extended file system ext2 and ext3 leading; plus distributed file systems, etc.) New ones still arriving ZFS, GoogleFS, Oracle ASM, FUSE File System Implementation We have system calls at the API level, but how do we implement their functions? On disk and in memory structures Boot control blockcontains info needed by system to boot OS from that volume Needed if volume contains OS, usually first block of volume Volume control block (superblock, master file table) contains volume details Total # of blocks, # of free blocks, block size, free block pointers or array Directory structure organizes the files Names and inodenumbers, master file table 2

3 File System Implementation (Cont.) Per file File Control Block (FCB)contains many details about the file inodenumber, permissions, size, dates NFTS stores into in master file table using relational DB structures File Permissions File dates (create, access, write) File owner, group, ACL File Size File data blocks or ptrto file data block Virtual File Systems (Cont.) The API is to the VFS interface, rather than any specific type of file system File System Interface VFSInterface Local FS type 1 Local FS type 2 Remote FS Disk SSD Network Contiguous Allocation Mapping from logical to physical Linked Allocation Block to be accessed = Q + starting address Displacement into block = R Example of Indexed Allocation Indexed Allocation Mapping (Cont.) Inode ptr Data Block Data Block Data Block Outer index Index Table File 3

4 Efficiency and Performance Efficiency dependent on: Disk allocation and directory algorithms Types of data kept in file s directory entry Pre allocationoras neededallocationof or as needed of metadata structures Fixed size or varying size data structures Efficiency and Performance (Cont.) Performance Keeping data and metadata close together Buffer cache separate section of main memory for frequently used blocks Synchronous writes sometimes requested by apps or needed by OS No buffering / caching writes must hit disk before acknowledgement Asynchronouswrites more common, buffer able, faster Free behind and read ahead techniques to optimize sequential access Reads frequently slower than writes Recovery Consistency checking compares data in directory structure with data blocks on disk, and tries to fix inconsistencies Can be slow and sometimes fails Use system programs to back updata from disk to another storage device (magnetic tape, other magnetic disk, optical) Recover lost file or disk by restoringdata from backup Log Structured File Systems Log structured(or journaling) file systems record each metadata update to the file system as a transaction All transactions are written to a log A transaction is consideredcommitted committed once it is written to the log (sequentially) Sometimes to a separate device or section of disk However, the file system may not yet be updated Log Structured File Systems The transactions in the log are asynchronously written to the file system structures When the file system structures are modified, the transaction is removed from the log Ifthefilesystemcrashes file crashes, allremaining transactions in the log must still be performed Faster recovery from crash, removes chance of inconsistency of metadata I/o Subsystem& LDD 4

5 I/O Hardware Variety of I/O dev : Storage, Transmission, Human interface Common concepts signals from I/O devices interface with computer Port connection point for device Bus daisy chainor shared direct access PCIbus common in PCs/Servers, PCI Express (PCIe) Peripheral Component Interconnect Expansionbusconnects relatively slow devices I/O Hardware Common concepts signals from I/O devices interface with computer Controller(host adapter) electronics that operate port, bus, device Sometimes integrated/separate circuit board Contains processor, microcode, private memory, bus controller, etc Some talk to per device controller with bus controller, microcode, memory, etc A Typical PC Bus Structure I/O Hardware (Cont.) I/O instructions control devices Devices usually have registers where device driver places commands, addresses, and data to write, or read data from registers after command execution Data in register, data out register, status register, control register Typically 1 4 bytes, or FIFO buffer Devices have addresses, used by Direct I/O instructions Memory mapped I/O Device data and command registers mapped to processor address space Especially for large address spaces (graphics) In your CS321 (Comp Peri. Interface) Device I/O Port Locations on PCs (partial) 8085 based Interfacing 8255 (I/O Interface Controller) 8254 (Timer) 8259 (Interrupt controller) 8237 (DMA Controller) 8251 (UART Controller) Microcontroller All controller are on Chip 5

6 Interrupts Polling can happen in 3 instruction cycles Read status, logical and to extract status bit, branch if not zero How to be more efficient if non zero infrequently? CPU Interrupt request linetriggered by I/O device Checked by processor after each instruction Interrupt handler receives interrupts Maskableto ignore or delay some interrupts Interrupt vector to dispatch interrupt to correct handler Context switch at start and end Based on priority, but some are nonmaskable Interrupt chaining if more than one device at same interrupt number Direct Memory Access Used to avoid programmed I/O(one byte at a time) for large data movement Requires DMAcontroller Bypasses CPU to transfer data directly betweeni/odeviceandmemory Direct Memory Access OS writes DMA command block into memory Source and destination addresses Read or write mode, Count of bytes Writes location of command block to DMA controller Bus BusmasteringofDMAcontroller grabs grabsbusfrombus CPU Cycle stealing from CPU but still much more efficient When done, interrupts to signal completion Version that is aware of virtual addresses can be even more efficient DVMA Application I/O Interface I/O system calls encapsulate device behaviors in generic classes Device driver layer hides differences among I/O controllers from kernel New devices talking already implemented protocols need no extra work EachOShasitsownI/Osubsystemstructuresanddevice has subsystem structures and device driver frameworks Devices vary in many dimensions Character stream orblock Sequentialor random access Synchronous orasynchronous (or both) Sharableordedicated Speed of operation read write, read only, orwrite only Characteristics of I/O Devices (Cont.) Subtleties of devices handled by device drivers Broadly I/O devices can be grouped by the OS into Block I/O Character I/O (Stream) Memory mapped file access Network sockets For direct manipulation of I/O device specific characteristics, usually an escape / back door Unix ioctl()call to send arbitrary bits to a device control register and data to device data register Block and Character Devices Block devices include disk drives Commands include read, write, seek Raw I/O,direct I/O,or file system access Memory mapped file access possible File mapped to virtual memory and clusters brought via demand paging DMA Character devices include keyboards, mice, serial ports Commands include get(), put() Libraries layered on top allow line editing 6

7 Network Devices Varying enough from block and character to have own interface Linux, Unix, Windows and many others include socket interface Separates network protocol from network operation Includes select()functionality Approaches vary widely (pipes, FIFOs, streams, queues, mailboxes) Clocks and Timers Provide current time, elapsed time, timer Normal resolution about 1/60 second Some systems provide higher resolution timers Programmable interval timerused for timings, periodic interrupts ioctl() (on UNIX) covers odd aspects of I/O such as clocks and timers Nonblockingand Asynchronous I/O Blocking process suspended until I/O completed Easy to use and understand Insufficient for some needs Nonblocking I/O call returns as much as available User interface, data copy (buffered I/O) Implemented viamulti multi threadingthreading Returns quickly with count of bytes read or written select() to find if data ready then read()or write()to transfer Asynchronous process runs while I/O executes Difficult to use I/O subsystem signals process when I/O completed Kernel I/O Subsystem Scheduling Some I/O request ordering via per device queue Some OSs try fairness Some implement Quality Of Service (i.e. IPQOS) Buffering store data in memory while transferring between devices To cope with device speed mismatch To cope with device transfer size mismatch To maintain copy semantics Double buffering two copies of the data Kernel and user, Varying sizes Full / being processed and not full / being used Copy on write can be used for efficiency in some cases Linux Kernel Split View Linux Device Driver Linux Device Driver by JonhantanCorbet 7

8 application call ret standard runtime libraries We would write mostof this source code app.cpp but we would call some library functions e.g., eg open(), read(), write(), malloc(), then our code would get linked with standard runtime libraries (So this is an example of code reuse ) call application ret standard runtime libraries user space syscall Many standard library functions perform services that require executing privileged instructions (which only the kernel can do) sysret Operating System kernel kernel space call application ret standard runtime libraries syscall sysret Linux allows us to write our own installable kernel modules and add them to a running system call module ret Operating System kernel Basic structure of a C program: Comment banner(showing title and abstract) Preprocessor directives (e.g., for header files) Global Globaldata declarations declarations(iftheyareneeded) they are needed) Required main() function (as the entry point) Can invoke printf() (for formatted output) Optionally may define some other functions user space kernel space #include<stdio.h>//headerfor printf int main(){ printf( \n Hello world\n ); return 0; We re allowed to install kernel objects: $ /sbin/insmod mylkm.ko We re Were allowed to remove kernel objects: $ /sbin/rmmod mylkm Anyone is allowed to list kernel objects: $ /sbin/lsmod 8

9 Kernel module differs from a normal C application program (e.g., no main() function) A kernel module cannot call any of the familiar functions from the standard C runtime libraries ForanyLKM LKM, twoentry points pointsaremandatory(one for initialization, and one for cleanup ) Resembles normal layout of C programs but Two module administration functions [these are required] plus Appropriate module service functions [these are optional] Module uses printk() instead of printf() Includes the <linux/module.h> header file Specifies a legal software license ( GPL ) Compilation requires a special Makefile Execution is passive (it s a side effect ) Module has no restriction on privileges int init_module( void ); // this gets called during module installation void cleanup_module( void); // this gets called during module removal A newer syntax allows memory efficiency: module_init(my_init); module_exit(my_exit); #include <linux/module.h> // for printk() int init( void ){ printk( "\n Kello, everybody! \n\n" ); return 0; void exit( void ){ printk( "\n Goodbye now... \n\n" ); MODULE_LICENSE("GPL"); module_init(init); module_exit(exit); You can modify the printk() text string so its message will be sure to be displayed it will be output to the graphical desktop Here s how you can do it: printk( <0> Hello, everybody! \n ); This log level indicates a kernel emergency 9

10 System Call Interface Device driver LKM layout Buffer Cache VFS File System Block Device Driver Character Device Driver Hardware Socket Network Protocol Network Device Driver the usual pair of module administration functions function function function... fops init exit module s payload is a collection of callback functions having prescribed prototypes AND a package of function pointers registers the fops unregisters the fops int open( char *pathname, int flags, ); int read( int fd, void *buf, size_t count ); int write( int fd, void *buf, size_t count ); int lseek( int fd, loff_t offset, int whence ); int close( int fd ); (and other less often used file I/O functions) UNIX systems treat hardware devices as special files, so that familiar functions can be used by application programmers to access devices (e.g., open, read, close) But a System Administrator has to create these device files (in the /dev directory) # mknod /dev/cmos c 70 0 Or alternatively (as we ve seen), an LKM could create these necessary device files #include <linux/module.h> // for printk() #include <linux/fs.h> // for register_chrdev() #include <asm/uaccess.h>// for put_user(), get_user() #include <asm/io.h> // for inb(), outb() char modname[] = "cmosram;// name of this kernel module char devname[] = "cmos;// name for the device's file int my_major= 70; // major ID number for driver int cmos_size = 128; // total bytes of cmos memory int write_max= 9; // largest 'writable' address ssize_tmy_read( structfile *file, char *buf, size_tlen, loff_t*pos ) { unsigned char datum; if ( *pos >= cmos_size) return 0; outb( *pos, 0x70); datum = inb( 0x71); if ( put_user( datum, buf) ) return EFAULT; *pos += 1; return 1; ssize_tmy_write( structfile *file, const char *buf, size_tlen, loff_t*pos ) { unsigned chardatum; if ( *pos >= cmos_size) return 0; if ( *pos > write_max) return EPERM; if ( get_user( datum, buf) ) return EFAULT; outb( *pos, 0x70 ); outb( datum, 0x71 ); *pos += 1; return 1; 10

11 loff_tmy_llseek( structfile *file, loff_tpos, intwhence ){ loff_tnewpos= 1; switch ( whence ) { case 0: newpos= pos; break; // SEEK_SET case 1: newpos = file >f_pos + pos; break; // SEEK_CUR case 2: newpos=cmos_ size+ pos; break;// SEEK_ END if (( newpos< 0 ) ( newpos> cmos_size)) return EINVAL; file >f_pos = newpos; return newpos; structfile_operationsmy_fops= { owner: THIS_MODULE, llseek: my_llseek, write: my_write, read: my_read, ; static int init my_init( void ) { printk( "<1>\nInstalling\'%s\' module ", devname); printk( "(major=%d) \n", my_major); return register_chrdev( my_major, devname, &my_fops); static void exit my_exit(void ) { unregister_chrdev( my_major, devname); printk( "<1>Removing \'%s\' module\n", devname); module_init( my_init); module_exit( my_exit); MODULE_LICENSE("GPL"); #include <stdio.h> // for printf(), perror() #include <fcntl.h> // for open() #include <unistd.h> // for read() intmain( intargc, char **argv){ intstatus = 0; int fd= open( "/dev/cmos", O_RDONLY ); if ( fd< 0 ){ perror( "/dev/cmos"); return 1; // Repeatedly reads Status_Reguntil its bit has 'flipped 30 times for(inti=0;i<30;i++){ i< i++) do {// do busy wait until UpdateInProgressis 'true' lseek( fd, 10, SEEK_SET ); read( fd, &status, 1 ); while (( status & 0x80 ) == 0x00 ); do{ // do busy wait until UpdateInProgressis 'false lseek( fd, 10, SEEK_SET ); read( fd, &status, 1 ); while (( status & 0x80 ) == 0x80 ); printf( "%d Second Elapsed\n", i+1 ); lspci nn Peripheral devices in the early PCs used fixed i/oports and fixed memory addresses, e.g.: Video memory address range: 0xA0000 0xBFFFF Programmable timer i/o ports: 0x40 0x43 Keyboard and mouse i/o ports: 0x60 0x64 Real Time Clock s i/o ports: 0x70 0x71 Hard Disk controller s i/o ports: 0x01F0 01F7 Graphics controller s i/o ports: 0x03C0 0x3CF Serial port controller s i/o ports: 0x03F8 0x03FF Parallel port controller s i/o ports: 0x0378 0x037A A non volatile parameter storage area for each PCI device function PCI Configuration Space Header (16 doublewords fixed format) 64 doublewords PCI Configuration Space Body (48 doublewords variable format) Dwords Status Register Command Register Device ID Vendor ID 1 0 BIST Header Latency Cache Class Code Revision Line Type Timer Size Class/SubClass/ProgIF ID 3 2 Subsystem Device ID BaseAddress 1 Base Address 3 Base Address 5 reserved Maximumm Minimumm Latency Grant Subsystem Vendor ID capabilities pointer Interrupt Line Interrupt Pin 16 doublewords BaseAddress 0 Base Address 2 Base Address 4 CardBus CIS Pointer Expansion ROM Base Address reserved

12 packet main memory buffer CPU B U S TX FIFO RX FIFO nic transceiver LAN cable Network Interface s hardware needs to implement filtering of network packets Otherwise the PC s memory usage and processor time will be wasted handling packets not meant for this PC to receive network packet s layout Destination address (6 bytes) Source address (6 bytes) Each data packet begins with the 6 byte device address of the network interface which is intended to receive it You can see the Hardware Address of the ethernetcontroller on your PC by typing: $ /sbin/ifconfig Look for it in the first line of screen output that is labeled eth0, for example: eth0 Link encap: Ethernet HWaddr00:11:43:C9:50:3A 31 0 Status Command Register Register Header Latency Cache BIST Line Type Timer Size Subsystem Device ID Maximum Latency BaseAddress1 Base Address 3 Base Address 5 reserved Minimum Grant Subsystem Vendor ID Interrupt Pin 16 doublewords capabilities pointer Interrupt Line 31 0 DeviceID 0x1677 VendorID 0x14E4 Class Code Class/SubClass/ProgIF BaseAddress0 Base Address 2 Base Address 4 CardBus CIS Pointer Expansion ROM Base Address reserved Revision ID Dwords #include <linux/pci.h> structpci_dev *devp; unsigned int iomem_base, iomem_size; void *io; devp= pci_get_device( 0x14E4, 0x1677, NULL ); if (!devp) return ENODEV; iomem_base= pci_resource_start( devp, 0 ); iomem_size= pci_resource_len( devp, 0 ); io= ioremap( iomem_base, iomem_size); if (!io) return EBUSY; SeetheDemos 12