The Coconut file system utilizing tape-based robotic storage

The Coconut file system: utilizing tape-based robotic storageCarl StaelinHewlett-Packard LaboratoriesRobotic storage devices offer large storage capacities at low cost, but with large access times. While such systems have been common in supercomputer sites for years,they are now becoming affordable for many more customers.One problem with these devices is the lack of system software to seamlessly incorporate them into the storage hierarchy. The Coconut file system extends the Sprite log-structured file system (LFS) toincorporate such devices into the file system.This is joint work with John Kohl and Mike Stonebraker of the University of California at Berkeley.1 IntroductionRobotic storage devices offer huge storage capacity with large seek times and fast sequential transfer rates,at very low cost per byte.Integrating these devices into the storage hierarchy will be the next challenge faced by file system designers.Coconut is being developed as part of the Sequoia 2000Project,and it includes both conventional disk and robotic tertiary storage in a single file system.Sprite LFS [Rosenblum91]was developed at the University of California at Berkeley by Mendel Rosenblum and John Ousterhout as part of the Sprite operating system.Its primary characteristic is that it is optimized for writing data,whereas most file systems are optimized for reading data.LFS divides the disk into 1MB segments and it writes data sequentially within each segment.The segments are threaded together to form a log,so recovery is simple.Disk space is reclaimed by copying valid data from dirty segments to the tail of the log,and then marking the segments clean.2 Robotic storage devicesRobotic storage devices include at least three major media types:tape,optical read/write disks,and optical WORM disks.Robotic tape devices have several advantages:high capacity per medium (tape cartridge),on-device compression/decompression,and extremely low cost per byte.Modern cartridge tape drives can stream data between 0.25and 50Mbytes per second and store between 5and 125Gbytes of data on a tape depending on the tape technology [Robinson90,Wood90].Finally,the cost is significantly lower than disk technology (a 2.0Gbyte disk costs $1.60 per Mbyte).3 Existing SystemsTertiary storage devices have been around and in common use at supercomputer sites for several years.Alternative technologies for making use of robotic (tape/optical)devices include:file migration/archival storage,the Inversion file system,and the Plan-9file system.File migration strategies copy whole files to and from the robotic storage [Smith81b].However,it is inefficient for large files (perhaps larger than the available disk capacity)which are only partially accessed.The Inversion file system is built on top of Postgres.It assumes that the database storage manager can control the robotic device,and it implements file storage by having each file be a single object Robot DeviceMedium Media Capacity Number of Media Maximum Storage Capacity Cost per Mbyte MetrumT ape (VHS)14.5GB 6009TB $0.001Exabyte-120T ape (8mm) 5.0GB 116580GB $0.17Exabyte-10T ape (8mm) 5.0GB 1050GB $0.20within thefile system relation.The Plan-9file system uses a WORM optical jukebox with disk as a cache for the jukebox.It makes no special effort to cluster block transfers to/from the jukebox [Quinlan91].4 Coconut file systemLog-structuredfile systems are a good match for archival storage,which is almost a write-only environment,since they are write-optimized.In order to optimize read performance,the cleaner, whichflushes data from disk to tape,must cluster“related”data together on tape.Data is read from tape in1Mbyte segments,so the cleaner tries to place closely related data within the same segment. We expect that data should be clustered in the following order:blocks within the samefile,files within the same directory,and directories within the same directory sub-tree.Coconut will also prefetch segments from tertiary storage using read-ahead algorithms and hints left by the cleaner. Coconut has a single block address space for both disk and tape blocks.Coconut allocates afixed amount of space to each tape,but since tapes hold a variable amount of data,this number is set to be the maximum amount of data the tape is expected to hold.Block addresses consist of a segment number and an offset within the segment.The segment number determines both the device(or tape cartridge)and the offset within the device(or tape)of the segment.Coconut can easily handle device-based compression on tape since it can keep writing segments to tape until the drive returns an“end-of-tape”message,at which point the tape is marked full and the last(partially written) segment is re-written onto the next tape.New data is written to disk-resident segments and is(eventually)migrated from disk to tape by the cleaner.The cleaner may create clean disk segments by copying data to the tail of either the active disk segment(this is how the cleaners in Sprite and4.4BSD LFS work)or the active tape segment. Disk segments can be used to cache tape segments.Tape-resident blocks are accessed through the disk-resident segment cache, which is read-only since old data is never over-written.Extending4.4BSD LFS to Coconut requires relatively few modifications.The cleaner must be able to migrate blocks from disk to tape.The block-fetch routine within Coconut has to understand the difference between disk-resident and tape-resident blocks,and a segment cache must be added to cache segments from tape on disk.5 ConclusionIn conclusion,I believe that robotic storage devices will become common in the near future,and that LFS on robotic tape storage devices is an attractive technology for transparently providingfile system services on low-cost mass-storage.6 References[Quinlan91] Sean Quinlan. A cached WORM file system.Software—Practice and Experience, 21(12):1289–99, December 1991.[Robinson90]Harriss Robinson.A mass storage subsystem using ANSI X3B6ID-1recorders.1990 IEEE 10th Symposium on Mass Storage Systems (Monterey, CA), pages 43–5, Karen D. Friedman and Bernard T. O’Lear, editors. IEEE catalog number 90CH2844-9, 7–10 May 1990. [Rosenblum91] Mendel Rosenblum and John K. Ousterhout. The design and implementation of a log-structured file system.Proceedings of 13th ACM Symposium on Operating Systems Principles (Asilomar,Pacific Grove,CA).Published as Operating Systems Review,25(5):1–15,13–16October 1991.[Smith81b] Alan Jay Smith. Optimization of I/O systems by cache disks and file migration: a summary.Performance evaluation,1:249–62. North-Holland, Amsterdam, 1981.[Wood90] Tracy G. Wood. A survey of DCRSi and D-2 technology.1990 IEEE 10th Symposium on Mass Storage Systems (Monterey, CA), pages 46–50, Karen D. Friedman and Bernard T. O’Lear, editors. IEEE catalog number 90CH2844-9, 7–10 May 1990.。