13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

208 File Structures Chapter 6a student file, a majors file, and a grade file. The exact details depend on the way thedatabase is structured, which must, of course, be known to the database management system.Large-scale database management systems often find themselves in conflict withthe policies forced upon them by the underlying operating system. These conflictsinclude physical disk allocation strategies, kernel caching (in particular, write-behind),and main-store management.4 FILE RECOVERYEvery user at some point accidentally deletes a file and thereby destroys many hours ofdiligent labor. It does not do much good to consider that repeating the labor will be mucheasier than doing it the first time and that the product will be better after this rework. Theoperating system can help reconstruct the lost file if necessary measures have been taken.Since recovering a lost file is a form of reliability, it is no surprise that all the techniquesthat the operating system might use involve redundancy of some form or another.4.1 DumpsAlmost all operating systems provide for a fairly large grain of redundancy: Every sooften, an archival copy (a dump) of files is made on magnetic tape. The unfortunate userwho has lost a file to accidental deletion can recover it by finding the most recent versionthat is stored on tape. Since storing all the files that exist might take many reels of tape, itis not reasonable to make complete archives very often. However, infrequent archivesincrease the chance that an archival copy of the deleted file, even if one exists, is far outof date.Instead, partial file dumps are commonly made every day. These tapes includeonly files that have been modified since the last partial backup. The user who accidentallydeletes a file can recover at least yesterday’s version, which is often better thannothing at all. If the file has not been modified for a few days, it can be found in a moreancient partial dump. Partial dump tapes may be reused after a few weeks; if so muchtime has elapsed since the file was last modified, it is likely to be on a full dump tape,which is saved for a much longer time.Instead of two classes of dump, one-day and total, we can devise a general schemethat tries to minimize the number of tapes needed but maximize the chances that we havesaved the file somewhere. Let’s assume that we have eight tapes. To keep things simple,we will pretend that a single tape is always long enough to hold all the files we dumpwhen we use that tape. (In reality, tapes 0 and 1 can be fairly short, but tapes 6 and 7 willhave to be quite long.) Number all the days that the operating system runs, starting withday 1. On day n , dump files on tape t , where 2 t is the highest power of 2 that divides n .For example, on day 51, we use tape 0, but on day 52, we use tape 2. On day 64, we use

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!