D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proc. of the Seventeenth ACM Symposium on Operating Systems Principles (SOSP), pages 110--123, 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....versioning costs, conventional versioning implementations still involve one or more new metadata blocks per version. On average, the metadata versions require as much space as the versioned data, halving the achievable detection window. Even with less comprehensive versioning, such as Elephant [37] or VMS [29] the metadata history can become almost ( 80 ) as large as the data history. This paper describes and evaluates two methods of storing metadata versions more compactly: journal based metadata and multiversion b trees. Journal based metadata encodes each version of a file s ....

....versioning and snapshots would provide similar reductions in versioned metadata. For on close versioning, this reduces the total space required by nearly 35 , thereby reducing the pressure to prune version histories. Identifying solid heuristics for such pruning remains an open area of research [37], and less pruning means fewer opportunities to mistakenly prune important versions. The rest of this paper is divided as follows. Section 2 discusses conventional versioning and motivates this work. Section 3 discusses the two space efficient metadata versioning mechanisms and their tradeoffs. ....

[Article contains additional citation context not shown here]

D. S. Santry, M. J. Feeley, N. C. Hutchinson, R. W. Carton, J. Ofir, and A. C. Veitch. Deciding when to forget in the Elephant file system. ACM Symposium on Operating System Principles. Published as Operating Systems Review, 33(5):110--123. ACM, 1999.

....will be a significant improvement to the extempore manual analysis techniques used today. 5 Related work Most previous works related with data system recovery use replication to enhance fault tolerance [6, 11] and use logging of updates to make roll back possible. Elephant file system [10] allows users to define retention policies which specify what files directories should be versioned. Its advantages include lower storage requirement and longer restore window. However, Elephant does not log each and every update so that it can not repair every possible damage. It requires users ....

D. S. Santry et. al. Deciding when to forget in the elephant file system. In Proceedings of the Seventeenth ACM Symposium on Operating Systems Principles, pages 110--123, December 12-15, 1999.

....use hashing to eliminate duplicate blocks within a file system [2, 18] or even locate similarities on non block aligned boundaries [13, 17] Such content overlap could also be used to identify related files, by treating files with large matching data sets as related. Often, users (or the system [19]) will keep several slightly different versions of a file. Although these files generally contain differences, often the inherent information contained within does not change (e.g. a user may keep three instances of their resume, each focused for a different type of job application) This gives ....

D. S. Santry, M. J. Feeley, N. C. Hutchinson, R. W. Carton, J. Ofir, and A. C. Veitch. Deciding when to forget in the Elephant file system. ACM Symposium on Operating System Principles. Published as Operating Systems Review, 33(5):110--123. ACM, 1999.

....modified. For instance, the Emacs text editor and the Framemaker word processor both automatically create a backup file storing the previous version of an edited file. Advanced and general solutions have been proposed at the kernel level for example, see the report on the Elephant file system [18] and its references. Nevertheless, it is relatively easy to come up with a good, quite general, and fairly OSneutral solution at the user level using dynamic libraries. Our versioning dynamic library interposes its own code to the symbols wrapping common system calls, like open, creat, unlink, and ....

....where the modified file exists. We have put this library to everyday use for source code files ( c, h, cpp, hpp, cc, hh, and .java suffixes) text files ( txt) etc. An interesting issue in versioning functionality is which of the older versions are worth keeping. The Elephant file system [18] allows users to specify policies for keeping older versions. Our library is primitive in this respect: it only keeps a fixed number of the most recent back versions (currently only one, but this can easily change) An interesting future improvement might be to provide versioning policies as other ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir, "Deciding when to forget in the Elephant file system", 17th ACM Symposium on Operating Systems Principles (SOSP'99).

....each benchmark application according to the SpecHint design, and the amount by which it increases the size of executables. The size increase due to shadow code mainly consists of the copy of the instructions in the original code section. has been the premise of several recent research projects [48, 58] that propose ways we can exploit this excess capacity. The table also breaks down the increase in binary sizes. These figures show that, as intended, the SpecHint support routines comprise a very modest amount of code and data (10 KB) It also shows that, for all cases except Sphinx, over half ....

Douglas S. Santry, Michael J. Feeley, Norma C. Hutchinson, Alistar C. Veitch, Ross W. Carton, and Jacob Ofir. Deciding when to forget in the Elephant file system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), 1999.

....in the storage system by capturing the state of a data item at some moment, with the expectation that this state can be accessed in the future. Retrieval points can be used to satisfy many needs, including protection against device failure, protection against user error or malicious actions [12, 14], protection against software errors or data corruption, legal requirements (e.g. audits) preserving a particular data state or a related set of data item states (e.g. archiving all the designs for a particular aircraft engine) and wanting to look at prior versions in case they still have ....

D. Santry, et al. "Deciding when to forget in the Elephant file system," Proc. of the 17th ACM Symposium on Operating Systems Principles (SOSP `99), December 1999, pp. 110 - 123.

....work by Yu and Vahdat [38] These distributed file systems may retain periodic checkpoints of previous system state, but they do not retain versions of individual files at a fine granularity, nor do they provide a simple interface to automatically retrieve these versions. OceanStore, like EFS [30], does keep all (or most) versions of files. Our system was designed to make time travel in OceanStore as simple as that in EFS. 2.2 Databases Although less related to OceanStore superficially, replicated database management systems (DBMSs) have developed many of the same ideas. Franklin et at. ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of ACM $05P, December 1999.

....i, so only those two new blocks (and their new parents) are added to the system; all other blocks are simply referenced by the same BGUIDs as in the previous version. cation model. As an additional benefit, it allows for time travel, as popularized by Postgres [34] and the Elephant File System [30]; users can view past versions of a file or directory in order to recover accidentally deleted data. Figure 1 illustrates the storage layout of a data object. Each version of an object contains metadata, the actual user specified data, and one or more references to previous versions. The entire ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of ACM SOSP, December 1999.

....uses of versioning other than self securing storage, such as recovery from system corruption and accidental file deletion. In particular, more space efficient versioning reduces the pressure to prune version histories. Identifying solid heuristics for such pruning remain an open area of research [37], so less pruning means fewer opportunities to mistakenly prune important versions. The rest of this paper is divided as follows. Section 2 discusses traditional versioning and motivates this work. Section 3 discusses two space efficient metadata versioning mechanisms and their tradeoffs. Section ....

....from user mistakes, recovery from system corruption, and analysis of historical changes. Each category stresses different features of the versioning system beneath it. Recovery from user mistakes: Human users make mistakes, such as deleting or erroneously modifying files. Versioning can help [16, 28, 37]. Recovery from such mistakes usually starts with some a priori knowledge about the nature of the mistake. Often, the exact file that should be recovered is known. Additionally, there are only certain versions that are of any value to the user; intermediate versions that contain incomplete data ....

[Article contains additional citation context not shown here]

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Ross W. Carton, Jacob Ofir, and Alistair C. Veitch. Deciding when to forget in the Elephant file system. ACM Symposium on Operating System Principles (Kiawah Island Resort, SC, 12--15 December 1999.

....reliability and archiving. In Farsite, there is little need for the former, since the multiple on line copies of each file on independent machines should be more reliable than a single extra copy on a backup tape whose quality is rarely verified. For archival purposes, automatic online versioning [40] would be a more valuable system addition than manual off line backup. However, if users still wish to backup their own regions of the namespace, existing backup utilities should work fme, except for two problems: pollution of the local cache and weakening of privacy from storing decrypted data on ....

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, J. Ofir, "Deciding When to Forget in the Elephant File System", 17th SOSP, Dec 1999.

....world of file storage and management. Though a hierarchical file system of directories and byte accessible files has been the norm for almost 30 years [27] the internals of file systems and underlying storage systems have evolved substantially, improving both performance [23] and functionality [33]. In file systems, many approaches have been developed to improve performance, including read optimized inode and file placement [23] logging of writes [30] improved meta data update methods [39] more scalable internal data structures [41] and off line reorganization strategies [22] However, ....

.... In the future, it would be interesting to investigate a range of policies on top of our redundancy mechanisms that automatically apply different redundancy strategies according to the class of a file, akin to how the Elephant file system segregates files for different versioning techniques [33]. Implementation: To accomplish our goal of per file redundancy, we decided to utilize separate and unique meta data for original and redundant files. This approach is natural within the file system as it does not require changes to on disk data structures. In our implementation, we use a ....

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding When To Forget In The Elephant File System. In Proceedings of the 17th ACM Symposiumon Operating Systems Principles (SOSP'99), pages 110--123, Kiawah Island Resort, SC, December 1999.

....primary server, which serializes them. A Harp system consists of a small cluster of well managed servers, probably physically colocated. Ivy does without any central cluster of dedicated servers at the expense of strict serial consistency. 7. 3 Reclaiming Storage The Elephant file system [34] allows all file system operations to be undone for a period defined by the user, after which the change becomes permanent. While Ivy does not currently reclaim log storage, perhaps it could adopt Elephant s version retention policies; the main obstacle is that discarding log entries would hurt ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of the ACM Symposium on Operating System Principles, pages 110--123, 1999.

....27 of users use between 1 100 MB; 38 of users use between 100 MB 1 GB of storage; and 11 of users consume more than 1 GB of storage each. Average file size in this set is 21.8 KB, matching results reported elsewhere [20] We treated this entire working set as being elastic. Previous studies [23] show that roughly half of all data on disk and 16 of files are regeneratable. Hence by treating all files as elastic, we are effectively modeling the cost of using rubberd on a disk consuming a total of 52 GB in 7.5 million files. Using EQFS mounted on LUFS, we ran three experiments with the ....

....of the reason for the much lower performance overhead of EQFS versus more generalized union file systems. The use of a disk cleaner to reclaim disk space consumed by elastic files has some similarities to mechanisms for supporting versioned files in file systems such as Cedar [24] and Elephant [22, 23]. Versioning file systems keep track of multiple versions of data automatically. As disk space fills up, versioning file systems reclaim disk space by discarding file versions according to some policy, such as discarding the oldest file versions first. The overall problem of supporting versioned ....

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

....Similarly, A3 is distributed across nodes 2, 3 and 4 and uses FedFS2. In this example, the local file system of node 2 is part of two federated file systems. A1 runs only on node 1 and uses the local file system directly. There is a significant body of research related to distributed file systems [4, 5, 3, 6, 7, 8, 9, 10, 1, 2, 11, 12]. Some recent projects include [13] the emerging industry standard DAFS [14] and wide area systems like [16, 17, 18, 19] In our project, we combine two technologies: the federated file system idea, and the remote memory communication support. Remote memory communication is the key ingredient of ....

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton and Jacob Ofir. Deciding when to forget in the Elephant file system. Proc. of SOSP (1999).

....availability. venti [4] provides versioning capability through a block level interface. It uses block level hashing to avoid storing redundant copies of block data. SnapMirror [5] provides versioning by taking advantage of meta data stored in the underlying file system. The Elephant file system [6] provides versioning capability and retention policies that can be applied at a file level. However, none of the above techniques provide semantic storage and retrieval capabilities. Besides, approaches based on the block level hashing does not handle misalignments in the objects. SFSRO [8] uses ....

Santry, D.S., et al. Deciding When to Forget in the Elephant File System. in 17th ACM Symposium on Operating Systems Principles (SOSP). 1999.

....cheap that it is feasible to retain snapshots permanently. The storage required to retain all daily snapshots of a file system is surprisingly modest; later in the paper we present statistics for two file servers that have been in use over the last 10 years. Like Plan 9, the Elephant file system [18] retains many versions of data. This system allows a variety of storage reclamation policies that determine when a version of a file should be deleted. In particular, landmark versions of files are retained permanently and provide an archival record. 3. The Venti Archival Server Venti is a ....

....Names [6] are another example of naming objects based on a secure hash of its contents. This work addresses the issue of naming and managing the various binary software components, in particular shared libraries, that make up an application. The philosophy of the Elephant file system [18] is similar to Venti; large, cheap disks make it feasible to retain many versions of data. A feature of the Elephant system is the ability to specify a variety of data retention policies, which can be applied to individual files or directories. These policies attempt to strike a balance between ....

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton and Jacob Ofir. Deciding when to forget in the Elephant file system. In Proceedings of the 17 Symposium on Operating Systems Principles, December 12-15, 1999.

....thus providing system administrators time to detect intrusions. For intrusions detected within this window, all of the version and audit information is available for analysis and recovery. The critical difference between self securing storage and user controlled versioning (e.g. Elephant [23][24], Cedar [13] or VMS [20] is that client side intruders can no longer bypass the versioning software by compromising complex OSes or their poorly protected user accounts. Instead, intruders must compromise enough storage nodes to defeat the thresholding mechanisms described in the previous ....

....was seen by Vogels Windows NT file usage study [29] 10 days worth of history data can be provided. The NT study consisted of 45 machines split into personal, shared, and administrative domains running workloads of scientific processing, development, and other administrative tasks. Santry, et al. [24] report a write data rate of 110MB per day. In this case, over 90 days of data could be kept. Their environment consisted of a single file system holding 15GB of data that was being used by a dozen researchers for development. 0 100 200 300 400 500 AFS 96 HPUX 99 NT 99 Time in Days Base ....

D. Santry, M. Feeley, N. Hutchinson, R. Carton, J. Ofir, and A. Veitch, "Deciding when to forget in the Elephant file system, "ACM Symposium on Operating System Principles, 1999.

....by accessing the archival layer. Files and directories in Silverback are named just like files in standard UNIX file systems. Users can append version numbers or timestamps to these names when they wish to access past versions in a similar syntax to that used in the Elephant file system [14]. Finally our filesytem code is similar to the Archival Filesystem Backup presented in figure 1. The only difference is instead of implementing the expensive SEARCH( function, we developed a more efficient meta object library, called MLib s. A MLib is metadata for a directory and contains an ....

....a byzantine agreement protocol can be used to provide consistency and conflict resolution for an archive in a fault tolerant manner. 7 Related Work The idea of using versioning as a means to providing time travel was first introduced with the Postgress database [15] The Elephant file system [14] studied the idea of time travel in a file system. Additionally, the 13 project examined schemes for reducing the storage overhead by understanding tradeoffs between the number of versions stored and the granularity of time travel possible. Several other projects use the idea of distributing data ....

SANTRY, D., FEELEY, M., HUTCHINSON, N., VEITCH, A., CARTON, R., AND OFIR, J. Deciding when to forget in the Elephant file system. In Proc. of ACM SOSP (Dec. 1999).

....hierarchical namespace. Presto achieves this using a virtual NFS server, while the Semantic File System integrates this functionality into the le system layer. Either mechanism could be used with Roma to provide access to the metadata server from Roma unaware applications. The Elephant le system[11] employs a sophisticated technique for tracking les across both changes in name and changes in inode number. 7 Conclusions We have described a system that helps ful ll the promise of personal mobility, allowing people to switch among multiple heterogeneous devices and access their personal les ....

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton and Jacob Or, \Deciding When to Forget in the Elephant File System." Proceedings of the Seventeenth ACM Symposium on Operating Systems Principles, December 12{ 15, 1999, Charleston, South Carolina. Pages 110-123. 13

....namespace. Presto achieves this using a virtual NFS server, while the Semantic File System integrates this functionality into the file system layer. Either mechanism could be used with Roma to provide access to the metadata server from Roma unaware applications. The Elephant file system[13] employs a sophisticated technique for tracking files across both changes in name and changes in inode number. 7. Conclusions We have described a system that helps fulfill the promise of personal mobility, allowing people to switch among multiple heterogeneous devices and access their personal ....

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton and Jacob Ofir, "Deciding When to Forget in the Elephant File System." Proceedings of the Seventeenth ACM Symposium on Operating Systems Principles, December 12--15, 1999, Charleston, South Carolina. Pages 110--123.

....and a simple transactional interface. # If application semantics allow it, this availability is provided at the expense of consistency. # In fact, groups of updates are combined to create new versions, and we plan to provide interfaces for retiring old versions, as in the Elephant File System [44]. 2 Finally, given the flexibility afforded by the naming mechanism and to promote hands off system maintenance, OceanStore exploits a number of dynamic optimizations to control the placement, number, and migration of objects. We classify all of these optimizations under the heading of ....

....completely self verifying. For the user, we provide a naming syntax which explicitly incorporates version numbers. Such names can be included in other documents as a form of permanent hyper link. In addition, interfaces will exist to examine modification history and to set versioning policies [44]. Although in principle every version of every object is archived, clients can choose to produce versions less frequently. Archival copies are also produced when objects are idle for a long time or before objects become inactive. When generating archival fragments, the floating replicas of an ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of ACM SOSP, Dec. 1999.

....from the trusted operating system code used by most systems. In general, we are concerned with two standard types of policy enforcement: 1 In fact, groups of updates are combined to create new versions, and we plan to provide interfaces for retiring old versions, as in the Elephant File System [50]. ffl Restricting readers In order to prevent unauthorized reads, we encrypt all data in the system which is not completely public, and distribute the encryption key to those users with read permission. ffl Restricting writers OceanStore writes must be signed, so that well behaved ....

....deep archival storage. For the user, we provide a naming syntax which explicitly incorporates version numbers. Such names can be included in other documents as a form of permanent hyper link. In addition, interfaces will exist to examine modification history and to set versioning policies [50]. New archival copies are generated at regular intervals and after a user selected number of updates. Although in principle every version of every object is 5 Tornado codes, which are faster to encode and decode, require slightly more than n fragments to reconstruct the information 10 ....

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of ACM SOSP, Dec. 1999.

....meta data locally, but each node need only replicate a portion of the file system. This design simplifies the overall implementation of the system and it simplifies how the system handles failures. It is also worth nothing that Mammoth extends the ideas of the single node Elephant file system [10], though it is implemented from scratch. As in Elephant, Mammoth users can rollback a file or directory to any point in the past by specifying a date and time as part of any pathname they provide to the file system. The system responds with the file and directory versions that existed at that ....

D. S. Santry, M. J. Feeley, N. C. H., A. C. Veitch, R. W. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proc. of the Seventeenth ACM Symposium on Operating Systems Principles (SOSP), pages 110--123, 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP '99), Kiawah Island, South Carolina, Dec. 1999.

No context found.

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, and Jacob Ofir. Deciding when to forget in the elephant file system. In Symposium on Operating Systems Principles, pages 110--123, 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Symposium on Operating Systems Principles, pages 110--123, 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proc. of the Seventeenth ACM Symposium on Operating Systems Principles (SOSP), pages 110--123, 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP '99), Kiawah Island, South Carolina, Dec. 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), Charleston, SC, USA, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110-- 123, December 1999.

No context found.

D.S. Santry, M.J. Feeley, N.C. Hutchinson, A.C. Veitch, R.W. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP'99), December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the pages 110--123, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), Charleston, SC, USA, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Proceedings of the 17th Symposium on Operating Systems Principles, pages 110--123, Kiawah Island Resort, South Carolina, U.S.A., 1999.

No context found.

D. J. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding when to forget in the elephant file system. In Proceedings of 17th ACM Symposium on Operating Systems Principles (SOSP), December 1999.

No context found.

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Ross W. Carton, Jacob Ofir, and Alistair C. Veitch. Deciding when to forget in the Elephant file system. ACM Symposium on Operating System Principles (Kiawah Island Resort, SC, 12--15 December

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110-- 123, December 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), Charleston, SC, USA, December 1999.

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP), Charleston, SC, USA, December 1999.

No context found.

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, and Jacob Ofir. Deciding when to forget in the Elephant file system. In Symposium on Operating Systems Principles, pages 110--123, 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R.W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 110--123, December 1999.

No context found.

D. Santry, et al, Deciding When to Forget in the Elephant File System, Proceedings of the Symposium on Operating System Principles (SOSP 1999).

No context found.

Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton, and Jacob Ofir, "Deciding when to forget in the Elephant file system," in Proceedings of the ACM Symposium on Operating Systems Principles (SOSP), pages 110--123, 1999. 110

No context found.

D. Santry, M. Feeley, N. Hutchinson, A. Veitch, R. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proc. of ACM SOSP, Dec. 1999. 9

No context found.

D. J. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding when to forget in the Elephant file system. In Proceedings of 17th ACM Symposium on Operating Systems Principles (SOSP), pages 110--123, December 1999.

No context found.

D. S. Santry, M. J. Feeley, N. C. Hutchinson, A. C. Veitch, R. W. Carton, and J. Ofir. Deciding When to Forget in the Elephant File System. In Proceedings of 17th SOSP, Dec. 1999.

First 50 documents  Next 50

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