Results 1 -
4 of
4
Transforming Policies into Mechanisms with Infokernel
- In Proceedings of the nineteenth ACM symposium on Operating systems principles
, 2003
"... We describe an evolutionary path that allows operating systems to be used in a more flexible and appropriate manner by higher-level services An inf okernel exposes key pieces of inf rmation about its algorithms and internal state; thus, its def ault policies become mechanisms, which can be controlle ..."
Abstract
-
Cited by 39 (9 self)
- Add to MetaCart
We describe an evolutionary path that allows operating systems to be used in a more flexible and appropriate manner by higher-level services An inf okernel exposes key pieces of inf rmation about its algorithms and internal state; thus, its def ault policies become mechanisms, which can be controlledf rom user-level We have implemented two prototype inf okernels based on the Linux 2 4 and NetBSD 1 5 kernels, called inf Linux and inf BSD, respectively The inf okernels export key abstractions as well as basic inf ormation primitives Using inf oLinux, we have implemented f ur case studies showing that policies within Linux can be manipulated outsideof the kernel Specifically, we show that the def ault file cache replacement algorithm, file layout policy, disk scheduling algorithm, and TCP congestion control algorithm can each be turned into base mechanisms For each case study, we havef ound that inf okernel abstractions can be implemented with little code and that the overhead and accuracyof synthesizing policies at user-level is acceptable Categories a n Subject Descriptors: D.4.7 [Operatin g Systems]: Organ inE in and Desi2 Ge n ral Terms: Desi9 , Experi51 tati1 , Performance Keywords: Poli) , MechaniE) Informatir 1.
DualFS: A New Journaling File System without Meta-data Duplication
- In Proceedings of the 16th International Conference on Supercomputing
, 2002
"... In this paper we introduce DualFS, a new high performance journaling file system that puts data and meta-data on different devices (usually, two partitions on the same disk or on different disks), and manages them in very different ways. Unlike other journaling file systems, DualFS has only one copy ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
In this paper we introduce DualFS, a new high performance journaling file system that puts data and meta-data on different devices (usually, two partitions on the same disk or on different disks), and manages them in very different ways. Unlike other journaling file systems, DualFS has only one copy of every meta-data block. This copy is in the metadata device, a log which is used by DualFS both to read and to write meta-data blocks. By avoiding a time-expensive extra copy of meta-data blocks, DualFS can achieve a good performance as compared to other journaling file systems. Indeed, we have implemented a DualFS prototype, which has been evaluated with microbenchmarks and macrobenchmarks, and we have found that DualFS greatly reduces the total I/O time taken by the file system in most cases (up to 97%), whereas it slightly increases the total I/O time only in a few and limited cases.
Symposium on Reliable Distributed Systems An Incremental File System Consistency Checker for Block-Level CDP Systems
"... A block-level continuous data protection (CDP) system logs every disk block update from an application server (e.g., a file or DBMS server) to a storage system so that any disk updates within a time window are undoable, and thus is able to provide a more flexible and efficient data protection servic ..."
Abstract
- Add to MetaCart
A block-level continuous data protection (CDP) system logs every disk block update from an application server (e.g., a file or DBMS server) to a storage system so that any disk updates within a time window are undoable, and thus is able to provide a more flexible and efficient data protection service than conventional periodic data backup systems. Unfortunately, no existing block-level CDP systems can support arbitrary point-in-time snapshots that are guaranteed to be consistent with respect to the metadata of the application server. This deficiency seriously limits the flexibility in recovery point objective (RTO) of block-level CDP systems from the standpoint of the application servers whose data they protect. This paper describes an incremental file system check mechanism (iFSCK) that is designed to address this deficiency for file servers, and exploits file system-specific knowledge to quickly fix an arbitrary point-in-time block-level snapshot so that it is consistent with respect to file system metadata. Performance measurements taken from a fully operational iFSCK prototype show that iFSCK can turn a 10GB point-in-time block-level snapshot to be file-system consistent in less than 1 second, and takes less than 25 % of the time required by the Fsck utility for vanilla ext3 under relaxed metadata consistency requirements. 1.
ffsck: The Fast File System Checker
"... Crash failures, hardware errors, and file system bugs can corrupt file systems and cause data loss, despite the presence of journals and similar preventive techniques. While consistency checkers such as fsck can detect this corruption and restore a damaged image to a usable state, they are generally ..."
Abstract
- Add to MetaCart
Crash failures, hardware errors, and file system bugs can corrupt file systems and cause data loss, despite the presence of journals and similar preventive techniques. While consistency checkers such as fsck can detect this corruption and restore a damaged image to a usable state, they are generally created as an afterthought, to be run only at rare intervals. Thus, checkers operate slowly, causing significant downtime for large scale storage systems when they are needed. We address this dilemma by treating the checker as a key component of the overall file system (and not merely a peripheral add-on). To this end, we present a modified ext3 file system, rext3, to directly support the fast file system checker, ffsck. The rext3 file system co-locates and self-identifies its metadata blocks, removing the need for costly seeks and tree traversals during checking. These modifications to the file system allow ffsck to scan and repair the file system at rates approaching the full sequential bandwidth of the underlying device. In addition, we demonstrate that rext3 performs competitively with ext3 in most cases and exceeds it in handling random reads and large writes. 1

