M. Baker, S. Asami, E. Deprit, J. Ousterhout and M. Seltzer, "Non-volatile memory for fast, reliable file systems" Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, Oct. 1992, 10-22  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to hide flash RAM s slow writes and bulk erases. The Durable Memory RS 6000 uses batteries, replicated processors, memory ECC, and alternate paths to tolerate a wide variety of hardware failures [1] Finally, many papers have examined the performance advantages and uses of reliable memory [17] [6], 12] 2] 45] 46] 7.2 Field Studies of Failures Studies have shown that software is the dominant cause of system outages [23] 24] and several studies have investigated system software errors. Sullivan and Chillarege classify software faults in the MVS operating system; in particular, ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "NonVolatile Memory for Fast Reliable File Systems," Proc. Fifth Int'l Conf. Architectural Support for Programming Languages and Operating Systems (ASPLOS-V), pp. 10-22, Oct. 1992.

....memory. In eNVy [17] copy on write and buffering were used to get around the long erase latency of flash RAM; this approach required extensive garbage collection similar to that used in log structured file systems [3,15] NVRAM has long been used for recovery and file system reliability [2], again with the restrictions of small size and coarse grained write access. In such systems, NVRAM is used as a non volatile cache for disk, but data lives on disk. This design improves file system reliability by reducing the window of vulnerability for written data and improves performance by ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-volatile memory for fast, reliable file systems," 5th Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pp. 10--22, 1992.

.... In a correction to that claim, Hartman and Ousterhout reported that 36 to 63 of the bytes written do not survive a 30 second window; this number jumps to 60 to 95 in a 1000 second window [Hartman93] According to another study, a small, non volatile file cache can reduce write traffic by 50 [Baker92]. Given that such short lifetimes mean that file cache blocks will be rewritten, we recommend that all operating system developers consider using a write cancellation policy, enabling writes to the file cache to perform at memory speeds. 4.3 Write Policy for Client Server Computing Thus far we ....

Mary Baker, Satoshi Asami, Etienne Deprit, John Ousterhout, and Margo Seltzer. NonVolatile Memory for Fast Reliable File Systems. In Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-V), pages 10-22, October 1992.

....for reducing access latency. Modern file systems generally use large RAM caches to speed up disk accesses. Such caches more effectively reduce read traffic than write traffic, since write requests must be frequently written into disks to protect them from data loss or damage due to system failures [2, 3, 4]. As the RAM size increases rapidly and absorbs more read requests, the proportion of write traffic seen by disk systems will dominate disk traffic and may potentially become a system bottleneck [4] While it is possible to improve the write performance by using Non volatile RAM (NVRAM) cache [2, ....

.... 3, 4] As the RAM size increases rapidly and absorbs more read requests, the proportion of write traffic seen by disk systems will dominate disk traffic and may potentially become a system bottleneck [4] While it is possible to improve the write performance by using Non volatile RAM (NVRAM) cache [2, 5], the write buffer size is usually very small compared to disk capacity because of the high cost of NVRAM 1 . Such a small buffer gets filled up very quickly and can hardly catch the locality of large I O data. Large NVRAM caches are cost prohibitive making it infeasible for many applications ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-volatile memory for fast, reliable file systems, " in Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating System (ASPLOS), (Boston, MA), pp. 10--22, ACM Press , New York, NY , USA, Oct. 1992.

....frequently transferring dirty data from the cache to disk. The use of NV write caches in client server environments and policies for managing them have been studied by several authors. Policies that have been studied include LRU replacement on servers [Moran et al. 90] LRU replacement on clients [Baker et al. 92] LRU write back on servers [Biswas et al. 93b] periodic write back on both servers and clients [Biswas et al. 93b] threshold based write back on both servers and clients [Biswas et al. 93a, Biswas et al. 93b] and piggybacking on servers [Biswas et al. 93a] This paper considers systems with ....

Baker, M., Asami, S., Deprit, E., Ousterhout, J., and Seltzer, M., "NonVolatile Memory for Fast, Reliable File Systems", Proceedings of the 5th International Conference on Architecture Support for Programming Languages and Operating Systems, Boston, MA, October 1992, pp.10-22.

....the GofflDrive. A third possible metric is the number of operations delayed. The metrics of number of reads delayed and number of operations delayed are very close; intuitively, if writes (including synchronous writes) can be decoupled from disk latency with a small amount of nonvolatile memory [BAD, RuWa], then the number of writes delayed can be ignored. Figure 7.2 shows the energy consumption and read spinup delays for the Powerbook traces, with a 1 Mbyte cache, and Figure 7.3 shows the same for the HP UX traces (which has an implicit buffer cache, as discussed above) Both figures show, for ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-volatile Memory for Fast, Reliable File Systems," Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (October 1992), 10--22, ACM.

....The use of Log Based File Systems [12] addresses this problem of improving the performance of writes. Another approach that is also becoming attractive is to use non volatile caches which allow for write behind rather than write through and thus reduce the number write operations to the disk [1, 7, 17]. This is partly because non volatile RAM (NV RAM) is becoming cheaper and it is easy to incorporate into existing system designs without major changes to the file system or the rest of the operating system. It must be noted, however, that NV RAM is still sufficiently expensive so that it is not ....

Baker, M., et al, "Non-Volatile Memory for Fast, Reliable File Systems," Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-V), October, 1992.

....disks are necessary only for cold data and permanent storage, to protect against system failures. This means that optimizations in this area are primarily focussed on write performance and reliability. Optimizations such as immediate writes [Wang99] or non volatile memory for fast write response [Baker92] are the most helpful 1 . These types of optimization can also benefit from increased intelligence at the individual devices to implement a variety of application optimized algorithms (such as 1. but not for individual disk drives, where the performance benefits of non volatile memory do not yet ....

Baker, M., Asami, S., Deprit, E., Ousterhout, J.K. and Seltzer, M.I. "Non-Volatile Memory for Fast, Reliable File Systems" ASPLOS, 1992.

....that must be performed. Updated objects can be buffered temporarily in safe RAM in case they are updated again. Should this occur, two (or more) disk writes will have been combined into one when the object is finally written to the disk. The disadvantage of safe RAM is its cost. A recent study [1] found that non volatile RAM was about five times as expensive as DRAM, although this cost differential is likely to drop over time. Given that some cost differential exists, it is reasonable to assume that buffers will be partially safe, i.e. they will be composed of a mix of safe RAM and ....

....direct transfer of data between the safe RAM and the disks is not possible. The focus of that work is on comparing the alternative safe RAM configurations, and not on buffer management. Two recent studies have used trace driven simulations to evaluate safe buffers in operating systems. One study [1] was based on traces from the Sprite file system, while the second used traces from Unix file systems [13] The traces used in [13] are block level traces similar to our own, while the Sprite traces are captured at a higher level. In particular, the Sprite traces do not include requests for file ....

[Article contains additional citation context not shown here]

Baker, Mary, S. Asami, E. Deprit, and J. Ousterhout, "Non-Volatile Memory for Fast Reliable File Systems", Proc. Int'l Conference on Architectural Support for Programming Languages and Operating Systems, October, 1992, pp. 10-22.

....decreasing price of RAM (current prices range from 35 to 65 per megabyte) will increase the size of file caches, which will help to hide disk latency. Finally, the increasing use of non volatile RAM, which is also becoming steadily cheaper, will hide the latency of disks even more effectively [Baker et al. 1992]. IPC latency cannot always be hidden. Some might argue that IPC performance is unimportant because its cost can often be hidden by overlapping it with other computation. First, it is impossible to hide the latency of local IPC. Although it is possible to hide some of the latency of remote IPC, ....

Baker, M., Asami, S., Deprit, E., Ousterhout, J., Seltzer, M., "Non-Volatile Memory for Fast, Reliable File Systems," Proc. 5th Symposium on Architectural Support for Programming Languages and Operating Systems, pp. 10-22, Oct. 1992.

....is full, it applies the modifications logged in NVRAM to the directories stored on disk. Because NVRAM is a reliable medium, this implementation provides the same degree of fault tolerance as the other implementations, while the performance is much better. A similar optimization has been used in [24, 30, 31, 32]. Using NVRAM, some sequences of directory operations do not require any disk operations at all. Consider the use of tmp. A file written in tmp is often deleted shortly after it is used. If the append operation is still logged in NVRAM when the delete is performed, then both the append and ....

....Simulations done by the authors show that the additional cost for their algorithm is low, while it provides better performance. Baker et al. have simulated and analysed the performance impact of NVRAM in two configurations: file caches in client workstations and write buffers in file servers [32]. The latter approach is comparable to our use of NVRAM in the directory service. Their measurements indicate that the addition of one half megabyte of NVRAM can decrease the number of disk acceses by 20 to 90 (in extreme cases) The results suggest that even at today s prices of NVRAM (four to ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-Volatile Memory for Fast, Reliable File Systems, " Proc. Fifth Int. Conf. on Architectural Support for Programming Language and Operating Systems, Boston, MA, pp. 10-22 (Oct. 1992).

....that page is written out to the stable transaction log. The stable transaction log can be stored in non volatile memory (NVRAM) instead of on a disk. NVRAM is much faster than disk storage, but is also much more expensive. Baker quotes NVRAM board costs ranging from 130 630 dollars per megabyte [3]. The higher PrimaryPrimary BackupBackup Log Log Commit UPS UPS Figure 2 3: A stable transaction log implemented by replication in the memories of a primary and a backup. Un interruptible power supplies are used to guard against power failures. costs are for small NVRAM boards where the fixed ....

....cycles in the dependency graph, and can also generate excessive disk writes. By storing modified metadata items separately instead of together in pages, the file system avoids introducing such false dependencies. Many file systems use non volatile memory to speed up synchronous meta data updates [3, 43, 30]. If NVRAM is available to an object oriented database, it can store the modified object buffer in this NVRAM and therefore avoid the necessity of having a separate stable transaction log. The Harp file system provides highly available storage for files [39] It is implemented with a ....

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer. Non-volatile memory for fast reliable file systems. In Architectural Support for Programming Languages and Operating Systems, pages 10--22, Boston, Massachusetts, 1992.

....level. As a result, it can be applied directly to current file systems without the need of changing the operating system. 1 Introduction Current disk systems generally use caches to speed up disk accesses. Such disk caches reduce read traffic more effectively than write traffic as shown in [1, 2, 3, 4]. As the RAM size increases rapidly and more read requests are absorbed, the proportion of write traffic seen by disk systems will dominate disk traffic and could potentially become a system bottleneck. In addition, small write performance dominates the performance of many current file systems ....

....RAID is very limited [6, 7] Caching is the main mechanism for reducing response times. Since all write operations need eventually be reflected on a disk, volatile cache may pose a reliability problem. Nonvolatile RAM (NVRAM) can be used to improve disk performance, particularly write performance [1, 8]. However, because of the high cost of nonvolatile RAMs, the write buffer size is usually very small compared to disk capacity. Such a small buffer gets filled up very quickly and can hardly catch the locality of large I O data. Increasing the size of nonvolatile cache is cost prohibitive making ....

[Article contains additional citation context not shown here]

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-volatile memory for fast, reliable file systems, " in Proceedings of the 5th International Symposium on Architectural Support for Programming Languages and Operating Systems (ASPLOS), (Boston, MA), pp. 10--22, Oct. 1992.

....memory is simple any store instruction by any kernel procedure can easily change any data in memory simply by using the wrong address. It is hence relatively easy for many simple software errors (such as de referencing an uninitialized pointer) to accidentally corrupt the contents of memory [Baker92a]. The main issue in protection is how to control accesses to the file cache. We want to make it unlikely that non file cache procedures will accidentally corrupt the file cache, essentially making the file cache a protected module within the monolithic kernel. To accomplish this, we use ideas from ....

....allow a reset and boot without erasing memory or the CPU caches [DEC94] the PCs we have tested do not. To make data accessible during a hardware failure, it should be possible to move a memory board to a different machine without losing power (just as disks can be moved without losing data) [Moran90, Baker92a]. 6 Related Work We divide the research related to this paper into two areas: field studies fault injection and protection schemes. 6.1 Field Studies and Fault Injection Studies have shown that software is the dominant cause of system outages [Gray90] and several studies have investigated ....

[Article contains additional citation context not shown here]

Mary Baker, Satoshi Asami, Etienne Deprit, John Ousterhout, and Margo Seltzer. Non-Volatile Memory for Fast Reliable File Systems. In Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-V), pages 10--22, October 1992.

....memory is simple any store instruction by any kernel function can easily change any data in memory simply by using the wrong address. It is hence relatively easy for many simple software errors (such as de referencing an uninitialized pointer) to accidentally corrupt the contents of memory [Baker92a]. The assumption that memory is unreliable hurts system performance, reliability, simplicity, semantics, and cost. Because memory is unreliable, systems that require high reliability, such as databases, write new data through to disk, but this slows performance to that of disks. Many systems, ....

....flash RAM s slow writes and bulk erases. The Durable Memory RS 6000 uses batteries, replicated processors, memory ECC, and alternate paths to tolerate a wide variety of hardware failures [Abbott94] Finally, several papers have examined the performance advantages and management of reliable memory [Copeland89, Baker92a, Biswas93, Akyurek95]. 3 Experimental Environment and Mechanisms Our experiments were run on DEC Alpha 3000 600 workstations (Table 1) running the Digital Unix V3.0 operating system. Digital Unix is a monolithic kernel derived from Mach 2.5 and OSF 1. What data does the user expect and want to remain intact after a ....

Mary Baker, Satoshi Asami, Etienne Deprit, John Ousterhout, and Margo Seltzer. Non-Volatile Memory for Fast Reliable File Systems. In Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-V), pages 10-- 22, October 1992.

....writes, but can cache data indefinitely, safe in the knowledge that data are persistent after a failure. On a system crash, the contents of the NVRAM can be written to disk or simply accessed during the reboot and recovery process. Baker and her colleagues quantify the benefits of such systems[1]. Such systems provide performance superior to both Soft Updates and journaling, but with the additional expense of NVRAM. The Rio system provides a similar solution [3] Rio assumes that systems have an uninterrupted power supply, so memory never loses its contents. Part of the normal main ....

Baker, M., Asami, S., Deprit, E., Ousterhout, J., Seltzer, M. "Non-Volatile Memory for Fast, Reliable File Systems," Proceedings of the 5th ASPLOS, pp. 10--22. Boston, MA, Oct. 1992.

....The cleaner uses this table to determine which segments to clean [ROSE90] Figure 2 shows the physical layout of the LFS. While FFS flushes individual blocks and files on demand, the LFS must gather data into segments. Usually, there will not be enough dirty blocks to fill a complete segment [BAKE92], in which case LFS writes partial segments. A physical segment contains one or more partial segments. For the remainder of this paper, segment will be used to refer to the physical partitioning of the disk, and partial segment will be used to refer to a unit of writing. Small partial segments ....

....such partial segments until it finds a later partial segment with SS DIROP set and SS CONT unset (i.e. the end of the directory operation write) If no such partial segment is ever found, then all the segments from the initial directory operation on are discarded. Since partial segments are small [BAKE92] this should rarely, if ever, happen. 4.4. Synchronization To maintain the delicate balance between buffer management, free space accounting and the cleaner, synchronization between the components of the system must be carefully managed. Figure 8 shows each of the synchronization relationships. ....

Baker, M., Asami, S., Deprit, E., Ousterhout, S., Seltzer, M., "Non-Volatile Memory for Fast, Reliable File Systems," Proceedings of the Fifth Conference on Architectural Support for Programming Languages and Operating Systems, Boston, MA, October 1992.

....segment. The cleaner uses this table to determine which segments to clean [ROSE90] Figure 6 2 shows the physical layout of LFS. While FFS flushes individual blocks and files on demand, LFS must gather data into segments. Usually, there will not be enough dirty blocks to fill a complete segment [BAKER92], in which case LFS writes partial segments. A physical segment contains one or more partial segments. For the remainder of this thesis, segment will be used to refer to the physical partitioning of the disk, and partial segment will be used to refer to a unit of writing. Small partial segments ....

....segments until it finds a later partial segment with SS DIROP set and SS CONT unset (i.e. the end of the directory operation write) If no such partial segment is ever found, then all the partial segments from the initial directory operation on are discarded. Since partial segments are small [BAKER92] this should rarely, if ever, happen. 6.3.4. Synchronization To maintain the delicate balance between buffer management, free space accounting and the cleaner, synchronization between the components of the system must be carefully managed. Figure 6 10 depicts the synchronization relationships. ....

[Article contains additional citation context not shown here]

Baker, M., Asami, S., Deprit, E., Ousterhout, S., Seltzer, M., "Non-Volatile Memory for Fast, Reliable File Systems," to appear in Proceedings of the Fifth Conference on Architectural Support for Programming Languages and Operating Systems, Boston, MA, October 1992.

....reduce seek times. Measurements show that the adaptive driver reduces seek times by more than half and reduces response time significantly. As LD can rearrange blocks dynamically, the proposed scheme can be applied to LD too. Baker et al. analyzed the impact of NVRAM on logstructured file systems [Baker et al. 1992]. They concluded that with 0.5 Mbyte of NVRAM the number of partially written segments can be reduced considerably; the number of disk accesses can be reduced by about 20 and on heavily used file systems it can even be reduced by about 90 [Baker et al. 1992] We expect that similar results can ....

....NVRAM on logstructured file systems [Baker et al. 1992] They concluded that with 0. 5 Mbyte of NVRAM the number of partially written segments can be reduced considerably; the number of disk accesses can be reduced by about 20 and on heavily used file systems it can even be reduced by about 90 [Baker et al. 1992]. We expect that similar results can be obtained for LLD. Carson and Setia present an analytical derivation of the optimal segment size in log structured file systems [Carson and Setia 1992] They show that large segments are good for write performance, but can have an adverse effect on read ....

Baker, M., Asami, S., Deprit, E., Ousterhout, J., and Seltzer, M., "Non-Volatile Memory for Fast, Reliable File Systems," Proc. Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, ACM SIGPLAN Notices, Vol. 27, No. 9, pp. 10-22, Boston, MA, Oct. 1992.

....The cleaner uses this table to determine which segments to clean [ROSE90] Figure 2 shows the physical layout of the LFS. While FFS flushes individual blocks and files on demand, the LFS must gather data into segments. Usually, there will not be enough dirty blocks to fill a complete segment [BAKE92], in which case LFS writes partial segments. A physical segment contains one or more partial segments. For the remainder of this paper, segment will be used to refer to the physical partitioning of the disk, and partial segment will be used to refer to a unit of writing. Small partial segments ....

....such partial segments until it finds a later partial segment with SS DIROP set and SS CONT unset (i.e. the end of the directory operation write) If no such partial segment is ever found, then all the segments from the initial directory operation on are discarded. Since partial segments are small [BAKE92] this should rarely, if ever, happen. Synchronization To maintain the delicate balance between buffer management, free space accounting and the cleaner, synchronization between the components of the system must be carefully managed. Figure 8 shows each of the synchronization relationships. ....

Baker, M., Asami, S., Deprit, E., Ousterhout, S., Seltzer, M., "Non-Volatile Memory for Fast, Reliable File Systems," to appear in Proceedings of the Fifth Conference on Architectural Support for Programming Languages and Operating Systems, Boston, MA, October 1992.

No context found.

M. Baker, S. Asami, E. Deprit, J. Ousterhout and M. Seltzer, "Non-volatile memory for fast, reliable file systems" Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, Oct. 1992, 10-22

No context found.

M. Baker, S. Asami, E. Deprit, J. Ousterhout, M. Seltzer, "Non-Volatile Memory for Fast, Reliable File System," Proc. of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pp 10-22, Boston, MA., October 1992.

No context found.

M. Baker, S. Asami, E. Deprit, J. Ousterhout and M. Seltzer, "Non-volatile memory for fast, reliable file systems" Proceedings of the Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, Oct. 1992, 10-22

No context found.

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, "Non-Volatile Memory for Fast, Reliable File Systems," Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems, Oct. 1992.

No context found.

M. Baker, S. Asami, E. Deprit, J. Ousterhout, and M. Seltzer, `Non-Volatile Memory for Fast, Reliable File Systems', Proceedings of the 5th International Conference on Architectural Support for Programming Languages and Operating Systems, pp. 10-22, Boston, MA, October 1992.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC