- per process table - table holds an index into the inode table, which has the handle for that file. Multiple opens have their own entries in the table - system open table - the system stores the mappings. This table is system wide. It's a cache for those translations. - inode table - a cache for file that are currently open and have been recently opened. - file backup/recovery - causes - system crashes (hardware or software) - physical: head crash (disk is usually dead, but some companies exist that claim they can get your data by recovering the head/tracks. But Smith says it's hard to do that because the crash leaves a scar on the tracks. - software: OS fails - power failure, natural disasters - user errors - rm -rf * - sabotage - approaches to recovery - periodic full dump (PFD) - at a certain frequency, dump ALL the files to a backup storage, such as tapes. Use these tapes to reload system upon crashes. Sometimes called periodic dumps - for consistency, system must be shut down. If files are modified during dumping, it defeats the purpose of dumping to maintain the most recent view of the system. - full dump slow with large amount of data. Need lots of tapes too. - it might not be bad for PCs but probably bad for servers. - hard drives are used to simulate tapes nowadays. Possible to get speed of HDs and capacity of tapes. - Astronomers and physicists use tapes for backup that are huge. - incremental (periodic) dump - dump only modified files since last dump - when user logs out or files is closed. - advantage over PFD is that you don't have to copy everything - recovering takes a long time - solutions to crash when modifying a file - work on a copy of the file, swap it for the original when done - new problems - what happens when multiple users modify a file? - usually the last saved modification is the only one that's saved - how to make the "swap" atomic? - write to a log instead. This is more crash resistant - write the modifications to the file before writing back to file - keep multiple copies. modify one and (carefully) copy the update to the 2nd. - smart way of doing it Old copy New copy --------------------------------------------------------- --------------------------------------------------------- | | | | | | | P' | | | | | | | | P* | --------------------------------------------------------- --------------------------------------------------------- | . . . . . . | (pointers into the list of blocks) | |---------------------| |--------------| | V V | ------------------------------------------------------------------------ | | | | | | | | | | | (file blocks) | ------------------------------------------------------------------------- | | --------- <--------------------------------------------------------| | | | | -------- Copy pointers to the file blocks and also any blocks that are to be modified and update the pointer int he new copy of pointers. When done modifying the file, simply use the new copy of pointers to represent the file and garbage collect the old copy. - There were many pictures he showed in bunches, but here are the punch lines - cache miss rates depend on work load. - don't trust "average". It could mean MANY things - miss ratio drops as more pages are brought in during look ahead - prefetching might be bad because the pages are brought in but are not useful NETWORKS - technology is increasing so fast that toaster with IPs might not sound that farfetched! - more and more computers are being networked. - it wasnt that big of a problem a decade ago, but is a big one today. - performance is very important. one delay that can't be avoided is that to transmit a signal between computers (sending a signal from California to Tokyo takes a while) - networks can be setup in multiple ways. Token ring is one possibility