8 April 2002 Operating Systems Memory Management wrap up File Management Read Nutt Ch 13 ------------------- Allocation strategies, cont. Linked FAT: file allocation table DOS OS2 modification to address faseter access section at beginning of partition for table table has one entry per block indexed by block directory entry: index of first block table entry: next block num, EOF, 0 (unused) still hop through FAT entries for random access faster than normal linked because all seeks in same part of disk sequential - may be slow FAT->DATA->FAT->DATA cache FAT lots of disk space Indexed index per file, not per partition array of disk block addresses overhead: index block large w.r.t. small files make smaller, but then cannot handle larger files UNIX inode - index node contains number links to a file owner's uid, gid times: access, modification, inode modification file size 12 disk block numbers single indirect pointer double indirect pointer triple indirect pointer performance, cache inodes when file opened store inodes close to file - preallocated on disk - fixed in number not wasteful for small files w/ 12 or fewer blocks with 4k disk blocks, files up to 16GB (using triple indirect) free space bit vector/ block status map free = 1 allocated = 0 HW to find free block + easy to identify nearby blocks + useful for disk recovery + space usage: 16GB disk with 1KB blocks needs 2^24 bits = 2048 blocks linked list - linked list of blocks - each block contains list of free blocks a 1kB disk block can hold 256 32 bit disk block numbers 16 GB disk with 1KB blocks needs free list of 16794 blocks to hold 2^24 disk block numbers + store list in some of the free blocks, no loss of disk capacity + easy to find free block + keep only one block of free list in memory - hard to manage spatial locality Consistency issues lose data from RAM - flush data periodically don't allow op to finish until write through to perm can get inconsistencies if part of op gets through but other part does not e.g., when system crashes block consistency search all inodes, count occurrences of each block in a file search free list, count occurrences of each block 1. blocks not marked free or in file, return to free list 2. blocks free and in file - remove from free 3. blocks in multiple files - copy and update inodes 4. blocks marked free multiple times - rebuild free list file consistency traverse directory structure - mark each file when reached if count same as value in inode - ok if count too high - set to lower value if count too low - set to higher value ------ Some real file systems ------ MSDOS 8+3 infinite nested directories no links, just tree no permissions directories stored as files directory entry: 32 bytes 8 file name 3 extension 1 attributes - read only, hidden, system 10 reserved 2 time 2 date 2 first block num 4 size - theoritically: up to 4GB files FAT - keeps track of file blocks FAT 12, 16, 32 = #bits a disk address contains originally, 512 byte blocks - max partition size: 2MB fine for floppy drives, but for hard drives: increase block sizes to 1KB, 2KB, and 4KB up to 16MB partitions with 4 partitions, up to 64MB disks then FAT16 - block sizes 8, 16, 32 fat table: 128KB largest partition: 2GB largest disk 8GB - (4 partitions) then FAT 32 WIN 98/ Win ME long file names - backward compatible with 8+3 convert long to short - remove spaces ~1, ~2 for conflicts dir entry: 8 base name 3 ext 1 attributes 1 NT 1 sec increase accuracy of time to 10 msec 4 creation time/date 4 last access 2 upper 16 bits of starting block 4 last write date/time 2 lower 16 bits of starting block 4 file size if file has long name, store in 1 or more dir entries preceeding MSDOS file name each entry holds up to 13 chars Long file name entry: 1 sequence - sequence of name entries 10 5 characters 1 attributes - set to 0x0F - otherwise impossible, ignored by MSDOS 1 0 1 checksum 12 6 chars 2 0 4 2 chars why checksum is necessary? create file under 987 boot into DOS remove file - does not tocuh extended file name create new file - using old dir entry