the efficiency of a simple cleaning policy based on cost and benefit. We have
implemented a prototype logstructured file system called Sprite. LFS; it
outperforms.
The Design and Implementation Log-Structured File System MENDEL
ROSENBLUM
University
of California
and JOHN
of a
K. OUSTERHOUT
at Berkeley
This paper presents a new technique for disk storage management called a log-structured file system, A log-structured file system writes all modifications to disk sequentially in a log-like structure, thereby speeding up both file writing and crash recovery. The log is the only structure on disk; it contains indexing information so that files can be read back from the log efficiently. In order to maintain large free areas on disk for fast writing, we divide the log into segments and from heavily fragmented segments. We use a segment cleaner to compress the live information present a series of simulations that demonstrate the efficiency of a simple cleaning policy based on cost and benefit. We have implemented a prototype logstructured file system called Sprite LFS; it outperforms current Unix file systems by an order of magnitude for small-file writes while matching or exceeding Unix performance for reads and large writes. Even when the overhead for cleaning is included, Sprite LFS can use 70% of the disk bandwidth for writing, whereas Unix file systems typically can use only 5 – 10%. Systems]: Storage Management–aUocCategories and Subject Descriptors: D 4.2 [Operating strategies; secondary storage; D 4.3 [Operating Systems]: File Systems Manation / deallocation organization, du-ectory structures, access methods; D.4. 5 [Operating Systems]: agement—file measurements, simReliability—checkpoint /restart; D.4.8 [Operating Systems]: Performance– ulation, operatzon anatysis; H. 2.2 [Database Management]: Physical Design— recouery and restart; H. 3 2 [Information Systems]: Information Storage —file organization General
Terms: Algorithms,
Design,
Measurement,
Performance
Additional Key Words and Phrases: Disk storage management, organization, file system performance, high write performance,
fast crash recovery, file system logging, log-structured, Unix
1. INTRODUCTION Over
the
last
access times
decade have
CPU
only
the future
and it will
To lessen
the
speeds
improved
cause more
impact
of this
have slowly.
This
and more
problem,
increased
dramatically
trend
is likely
applications
we have
devised
while
disk
to continue
to become a new
in
disk-bound. disk
storage
The work described here was supported m part by the National Science Foundation under grant CCR-8900029, and in part by the National Aeronautics and Space Administration and the Defense Advanced Research Prolects Agency under contract NAG2-591. Authors’ addresses: J. Ousterhoust, Computer Science Division, Electrical Engineering and Computer Sciences, University of California, Berkeley, CA 94720; M. Rosenblum, Computer Science Department, Stanford University, Stanford, CA 94305. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. @ 1992 ACM 0734-2071/92/0200-0026 $01.50 ACM Transactions
on Computer
Systems,
Vol
10,
No.
1, February
1992,
Pages
26-52
The Design and Implementation management technique an order of magnitude Log-structured cached
in
caches
more
disk
traffic
writes This
file
main
all
called a log-structured more efficiently than systems
memory
and more will
approach
and
are
based
that
effective
become
new
of a Log-Structured
write
read
by writes.
examine
consistency the most
The notion incorporated recovery
[8, 9]. However, the permanent
storage
structure
For
but
permanently
file
large
segments
other
systems
contrast,
system the
log.
by eliminating
file
system
system
extents
use the log only
al-
need only
a log-structured
files
can
to operate
of free
for temporary
is in a traditional
is no other
so that systems.
structure
file
system
on disk.
be read
back
efficiently,
space available design based
random-access stores
The log con-
with
efficiency
it must
ensure
that
for writing
new
data.
of a log-structured on large extents
file called
to explore different cleaning policies and discovered a algorithm based on cost and benefit: it segregates older,
slowly changing data from differently during cleaning.
We have
file called
where a segment cleaner process continually regenerates empty by compressing the live data from heavily fragmented segments.
We used a simulator simple but effective more them
As a result,
also permits much faster must scan the entire disk
a log-structured
This is the most difficult challenge in the system. In this paper we present a solution segments,
are the
and a number of recent file systems have structure to speed up writes and crash
in the log: there
a log-structured are always
In
files make
of the log.
these
on disk.
[18].
structure
dramatically
home for information
tains indexing information comparable to current file there
a crash, portion
of logging is not new, a log as an auxiliary
storage; data
after
recent
that
sizes will
requests
27
uses disks
A log-structured
most all seeks. The sequential nature of the log crash recovery: current Unix file systems typically to restore
assumption
in a sequential
performance
which systems.
file
memory
at satisfying
to disk
increases
on the
.
system,
current
increasing
dominated
information
file
File System
constructed
a prototype
younger
rapidly
changing
log-structured
file
data
system
and
called
treats Sprite
LFS, which is now in production use as part of the Sprite network operating system [17]. Benchmark programs demonstrate that the raw writing speed of Sprite LFS is more than an order of magnitude greater than that of Unix for small files. Even for other workloads, such as those including reads and large-file accesses, Sprite LFS is at least as fast as Unix in all cases but one (files read sequentially after being written randomly). long-term overhead for cleaning in the production LFS permits about 65-75% of a disk’s raw bandwidth
We also measured the system. Overall, Sprite to be used for writing
new data (the rest is used for cleaning). For comparison, Unix systems can only utilize 5-1090 of a disk’s raw bandwidth for writing new data; the rest of the time is spent seeking. The remainder of this paper reviews the issues in designing
is organized file systems
into six sections. Section 2 for computers of the 1990s.
Section 3 discusses the design alternatives for a log-structured file system and derives the structure of Sprite LFS, with particular focus on the cleaning mechanism. Section 4 describes the crash recovery system for Sprite LFS. ACM
Transactions
on Computer
Systems,
Vol.
10, No.
1, February
1992.
28
.
Section
M. Rosenblum and J. K. Ousterhout 5 evaluates
measurements file
systems,
2. DESIGN
Sprite
LFS
of cleaning and Section
using
overhead.
benchmark Section
programs
6 compares
and
Sprite
long-term
LFS
to other
7 concludes.
FOR FILE SYSTEMS
OF THE 1990’s
File system design is governed by two general forces: technology, provides a set of basic building blocks, and workload, which determines of operations technology system Sprite
that
design. LFS
be carried
that
are
and shows
how
out
efficiently.
underway
It also describes
the workloads 2.1
must
changes
file
This
describes
the workloads
current
and technology
and
that
systems
section their
summarizes
impact
influenced
which a set
the
are ill-equipped
on file design
of
to deal with
changes.
Technology
Three
components
of technology
are particularly
significant
for
file
system
design: processors, disks, and main memory. Processors are significant because their speed is increasing at a nearly exponential rate, and the improvements seem likely to continue through much of the 1990s. This puts pressure on all the other elements of the computer system to speed up as well, the system doesn’t become unbalanced. Disk technology is also improving rapidly, but the improvements been
primarily
There
are
access time. improvement
in the
two
Although is much
can be improved disks [19], but determined tion
causes
application
areas
components
of cost and of disk
both slower
capacity
rather
performance:
motions
that
a sequence
of small
is not likely
to experience
disk
are hard
transfers much
performance.
separated
and
the rate of bandwidth
and parallel-head access time (it
to improve).
speedup
have
bandwidth
of these factors are improving, than for CPU speed. Disk transfer
substantially with the use of disk arrays no major improvements seem likely for
by mechanical
than
transfer
so that
is
If an applica-
by seeks,
over the next
then
the
ten years,
even with faster processors. The third component of technology is main memory, which is increasing in size at an exponential rate. Modern file systems cache recently used file data in main memory, and larger main memories make larger file caches possible. This
has two effects
on file
system
behavior.
First,
larger
file
caches alter
the
workload presented to the disk by absorbing a greater fraction of the read requests [2, 18]. Most write requests must eventually be reflected on disk for safety, so disk traffic (and disk performance) will become more and more dominated by writes. The second impact of large file caches is that they can serve as write buffers where large numbers of modified blocks can be collected before writing any of them to disk. Buffering may make it possible to write the blocks more efficiently, for example by writing them all in a single sequential transfer with only one seek. Of course, write-buffering has the disadvantage of increasing the amount of data lost during a crash. For this paper we will assume that crashes are infrequent and that it is acceptable to lose a few ACM
TransactIons
on
Computer
Systems,
Vol.
10,
No
1, February
1992
The Design and Implementation of work seconds or minutes crash recovery, nonvolatile 2.2
of a Log-Structured
.
29
in each crash; for applications that require RAM may be used for the write buffer.
better
Workloads
Several tions.
different
file
One of the
system
most
is found efficiently neering applications
in
workloads
difficult
found
dominated
for file
not
such
files
system
sequentially
out
focus on the efficiency
2.3
LFS
Problems
Current them
file
spread
work
well
systems
information
separate
disk,
It takes
name.
files.
the file’s
as those but
for ensuring
performance
and leave
accesses.
for large
from
two
the
files
that
tends
it to hardware
Fortunately,
as well
general and
disk
to be
design-
the techniques
as small
problems
workloads a way
in
Furthermore, contents,
at least
exist
so 1/0
accesses,
technologies
around
different from
such
problems,
and memory subsystems rather than the a log-structured file system we decided to
ones.
five
the
as is the
separate
that
causes
attributes 1/0s,
make
it hard
1990s.
First,
for they
too many
small
system (Unix FFS) [121 is on disk, but it physically
directory
disk
that
of the
accesses. For example, the Berkeley Unix fast file out each file sequentially quite effective at laying separates
files,
File Systems
suffer the
to large
of techniques
for large-file
with Existing
to cope with
to handle
to file system and blocks of
also pose interesting
on
of small-file
bandwidth
used in Sprite
accesses
A number
limited by the bandwidth of the 1/0 file allocation policies. In designing to improve
applica-
designs
dominated by updates to locate the attributes
environments,
software.
laid
are
computer
in
system
file sizes of only a few kilobytes [2, 10, 18, 231. small random disk 1/0s, and the creation and
by sequential
supercomputing
in
for file
office and engineering environments. Office and engitend to be dominated by accesses to small files; several
deletion times for such files are often “ metadata” (the data structures used the file). Workloads
common
are
workloads
studies have measured mean in Small files usually result
ers
File System
(” inode”) entry
for
a
containing
each preceded
file
the
are file’s
by a seek, to
FFS: two different accesses to the file’s attributes create a new file in Unix data, and the directory’s plus one access each for the file’s data, the directory’s small files in such a system, less than 5% of the is used for new data; the rest of the time is spent
attributes. When writing disk’s potential bandwidth seeking. The second
problem
synchronously:
the
than
continuing
even
though
metadata
while Unix
the
FFS
structures
chronously. nated
with
by
application’s application
For the
current
application write
such
file as
with
data
many
synchronous
metadata to
from
for
CPUS.
ACM Transactions
the
they to
the
background. inodes
files,
the
disk
also
and
example
file
system
written
writes the
write
For
traffic
make
defeat
to
rather
are
Synchronous disk
They
tend
complete,
asynchronously,
small
of
that
write
and
writes.
that
faster
in
is
the
blocks
directories
performance to benefit
systems
wait
is handled
writes
workloads
file
must
it
synis
domi-
couple hard
potential
the
for use
the of
on Computer Systems, VO1 10, No 1, February 1992
30
M. Rosenblum and J. K. Ousterhout
.
the file cache as a write [21] to
have
buffer.
Unfortunately,
network
introduced
additional
synchronous
This
simplified
crash
exist.
has
behavior
recovery,
but
file
systems
like
NFS
where
it
not
used
it
has
did
reduced
write
performance. Throughout FFS)
this
paper
as an example
tured
file
mented The
systems.
in the
The
most
3. LOG-STRUCTURED The
fundamental
performance and
then
data
all
the
used
not
system
it
Unix
(Unix
it to log-struc-
because
unique
to
is
well
operating
to Unix
disk
the
docu-
systems.
FFS
and
can
writes
sequential
file
For
that
file
can
utilize
the
a single
operation
and
system
traditional
in
in
write
system. file
of
transfers
sequentially in the
is to improve
changes
directories
log-structured
random
system
system
to disk
blocks,
manage
a
file
of file
written index
to
files,
synchronous chronous
changes
attributes,
small
are
a sequence
information
information many
section
used
file
compare
popular
of a log-structured
The
blocks,
is
several
fast
and
systems.
buffering
writing
operation.
design in
Unix
design
FILE SYSTEMS
idea
by
FFS
this
file
Berkeley
system
used
in
other
the
file
and
presented
in
use
Unix
literature
problems
be found
we
of current
write
file
cache
disk
write
includes
almost
all
workloads
file
the
that
other contain
converts
the
many
small
systems
into
large
asyn-
nearly
100~o
of the
raw
disk
bandwidth. Although two
the
key
logging this the
free
for
writing
space
The
used
Sprite
by
in
LFS
detail
LFS.
to Our
goal
cal
to
called
an
sions, more
indirect
In
ten
Once the each
a file,
ACM Transactions
available
data
data
log;
manage
is the
on-disk the
on
or exceed
the
read
basic
each
the
inode
also
of which
a file’s
inode
topic
of
structures
structures
Systems,
Vol.
there ten the the
been
found,
in
Sprite
LFS
location
10,
yields No
the
performance
contains
calculation
sequential
is not
are
by
1, February
Sprite
LFS
disk 1992
are
given
identi-
structure
owner, file;
permisfor
files
of one
of more
number Unix
To
to permit
addresses
addresses
are
Sprite
FFS.
log
of the
disk the
in
a data
(type, blocks
on disk; the
in the
exists
and
scans
case
of Unix
structures
has
is at a fixed
that
attributes first
contains
is identical
inode
this
used file
file’s
of the
each
a simple
index
structures
for
addresses
file
Computer
outputs
FFS;
the
suggest log,
contains
disk
blocks,
FFS for
might the
The
blocks,
to read
Unix
always it
the
to
paper.
from
LFS
Unix
which the
blocks.
number
Sprite
in
inode,
than
indirect
to match
used
larger
are
are of the
from
is how
issue;
of the
problems;
of the
information
goal,
etc. ) plus
required
above
the
sections
space
difficult
solve
retrievals.
those
of free
issue
there
benefits
information
second
more
“log-structured”
was
this
random-access
extents
a much
is simple,
potential
and Reading
retrieve
accomplish
The
a summary
later
the
to retrieve
I contains
to in
system
achieve
below.
large is
file
to
is how
3.1
This
Table
the term
required
issue
so that
data.
File Location
Although
first
on disk
3.2-3.6.
be resolved
of Section
new
Sections
of a log-structured
must
subject
discussed
idea
that
approach.
is the
3.1
basic
issues
data
of disk
or or
1/0s
FFS. the
address
identifying of the
file’s
The Design and Implementation Table I.
Summary
of the Major
Data structure Incde Inmfe map
of a Log-Structured
Data Structures
File System
Purpose
Segmentusage!able Superblock Checkpoint region Dmxtory changelog
31
Stored on Disk by Sprite LFS.
Locates blocks of file, holds protection bits, modify time, etc. Locates posiuon of mode in log, holds time of fast accessPIUS version number. Locates blocks of large files. Identifies contents of segment (file number and offset for each block). stomalastwrite timefor Counts live bytes still left in segmen!s, data in segments. Hotds static configuration information such as numlxr of segments and segmentsize. Locates blocks of inode map and segmentusagetable, identifies last checkpoint in log. Records directory opxations to maintain consistency of referencecounts in inodes.
Indirect block Segmentsummary
.
Location Log Log
Section
Log Log
3.1 3.2
Log
3.6
Fixcd
None
Fixed
4.1
Log
4.2
3.1 3.1
For each data structure the table indicates the purpose served by the data structure in Sprite LFS. The table also indicates whether the data structure is stored in the log or at a fixed position on disk and where in the paper the data structure is discussed in detail. Inodes, indirect blocks, and superblocks are similar. to the Unix FFS data structures with the same names. Note that Sprite LFS contains neither a bitmap or a free list.
inode.
In contrast,
written
to the
maintain
the
for a file, inode.
Sprite
log.
current
the inode
The inode
checkpoint blocks.
doesn’t
LFS
map must on each
cached
in
into
main
are
memory:
Given
that the
the
an
the disk
locations
to
lookups
are
to
map
number
address
of the
to the log; a fixed
of all
enough
map
they
inode
identifying
are written
compact
inode
positions;
called
to determine
blocks
identifies
maps
at fixed
structure
inode.
be indexed
disk
inode
inodes
a data
of each
map is divided
region
place
uses
location
Fortunately,
portions
LFS
Sprite
the
inode
keep
rarely
the
map active
require
disk
accesses. Figure FFS
1 shows
after
layouts
creating
have
duces a much
the
3.2
The most ment
difficult
layouts
new
files
logical
compact
is much
Free Space
disk
two same
more
of Sprite LFS just as good.
the
structure,
arrangement.
better
Management: design
that
would
in different
than
Unix
the
occur
in Sprite
LFS
directories.
Although
log-structured
file
As a result, FFS,
while
the write its read
and Unix the
system
two pro-
performance
performance
is
Segments
issue
for log-structured
of free space. The goal is to maintain
file
large
systems
is the manage-
free extents
for writing
new
data. Initially all the free space is in a single extent on disk, but by the time the log reaches the end of the disk the free space will have been fragmented into many small overwritten. From this point
extents
corresponding
on, the file
system
to
the
files
has two choices:
that
were
threading
deleted
or
and copying.
These are illustrated in Figure 2. The first alternative is to leave the live data in place and thread the log through the free extents. Unfortunately, threading will cause the free space to become severely fragmented, so that large contiguous writes won’t be possible and a log-structured file system will ACM Transactions
on Computer Systems, Vol. 10, No. 1, February 1992.
32
.
M, Rosenblum and J. K. Ousterhout
dirl
dir2
filel Lag +
Disk Sprite
filel
.* &w ~:
file2 ‘1 ~ ~: ,, ,:::
~= ..... :;I ,,,,
+
LFS
‘? dirl
file2
... ;: !!J ~ dir2
& Disk Unix FFS
Fig. 1. A comparison between Sprite LFS and Unix FFS. This example shows the modified disk blocks written by Sprite LFS and Unix FFS when creating two single-block files named dirl /filel and dlr2 /flle2. Each system must write new data blocks and inodes for file 1 and flle2, plus new data blocks and inodes for the containing directories. Unix FFS requires ten nonsequential writes for the new information (the inodes for the new files are each written twice to ease recovery from crashes), while Sprite LFS performs the operations in a single large write. The same number of disk accesses will be required to read the files in the two systems. Sprite LFS also writes out new inode map blocks to record the new inode locations
Block
Copy and Compact
Threaded log
Key:
Old data block New data block Prcwously deleted
la
Old log end
New log end
Old log end
New log end
II II
Fig, 2. Possible free space management solutions for log-structured file systems, In a log-structured file system, free space for the log can be generated either by copying the old blocks or by threading the log around the old blocks. The left side of the figure shows the threaded log approach where the log skips over the active blocks and overwrites blocks of files that have been Pointers between the blocks of the log are mamtained so that the log can deleted or overwritten. be followed during crash recovery The right side of the figure shows the copying scheme where log space is generated by reading the section of disk after the end of the log and rewriting the active blocks of that section along with the new data into the newly generated space.
be no faster than traditional file systems. The live data out of the log in order to leave large
second alternative is to copy free extents for writing. For
this paper we will assume that the live data is written back in a compacted form at the head of the log; it could also be moved to another log-structured file system to form a hierarchy of logs, or it could be moved to some totally different file system or archive. The disadvantage of copying is its cost, particularly for long-lived files; in the simplest case where the log works circularly across the disk and live data is copied back into the log, all of the long-lived files will have to be copied in every pass of the log across the disk. Sprite LFS uses a combination of threading and copying. The disk is segments. Any given segment is divided into large fixed-size extents called always written sequentially from its beginning to its end, and all live data must be copied out of a segment before the segment can be rewritten. However, the log is threaded on a segment-by-segment basis; if the system ACM
Transactions
on
Computer
Systems,
Vol.
10,
No.
1, February
1992,
The Design and Implementation can
collect
long-lived
data
skipped
over
segment
size is chosen
whole
so that
segment
segment.
This
bandwidth
cessed. Sprite
data
large
into
doesn’t
enough
greater
allows
of the
together
the
is much
of a Log-Structured
that
than
segments
to be copied
the transfer
operations
regardless
LFS currently
those
.
33 can be
repeatedly.
time
to read
The
or write
the cost of a seek to the beginning
whole-segment
disk,
segments, have
File System
of the
to run
order
uses segment
at
in which
sizes of either
a
of the
nearly
the
segments
full
are
512 kilobytes
ac-
or one
megabyte.
3.3
Segment
Cleaning
Mechanism
cleaning. The process of copying live data out of a segment is called segment In Sprite LFS it is a simple three-step process: read a number of segments
into
memory,
number that
identify
of clean
were
read
additional As part
the live
segments.
are marked
cleaning. of segment
each segment possible
file
the live
operation
and they
it must
so that
the
and write this
as clean,
cleaning
are live,
to identify
data, After
they
back
to a smaller the
segments
can be used for new data
be possible
to identify
can be written
to which
data
is complete,
which
out again.
each block
belongs
blocks
It must
and the
or for of
also be
position
of
the block within the file; this information is needed in order to update the file’s inode to point to the new location of the block. Sprite LFS solves both of these problems
by writing
The summary segment; the
for
file
multiple fill
the
blocks
a segment
identifies
example,
for
number
and
segment
summary
segment.
crash
each
block
in the
blocks
file
recovery
data
number blocks
file
impose
summary
as part
block
each piece of information the more
writes
cache
little
block
for
when
(Partial-segment
buffered
summary during
block
the block.
(see Section
during
4) as well
block
Segments the
in the contains
can
one log write
when
is insufficient
overhead
is written
summary
than
occur
of each segment.
that
contain
is needed
number
to
of dirty
to fill
a segment).
Segment
writing,
and they
are useful
as during
cleaning.
Sprite LFS also uses the segment summary information to distinguish live blocks from those that have been overwritten or deleted. Once a block’s identity is known, its liveness can be determined by checking the file’s inode or indirect
block
to see if the
block.
It it does, then
Sprite
LFS
the
inode
ever the file bined
with
optimizes
map
entry
is deleted the
inode
the
appropriate
block
is live;
if it doesn’t,
block
this
check
for each file; or truncated number
form
slightly
by
the version
pointer then
still
refers
the
block
keeping
a version
number
is incremented
to length
zero, The version
a unique
identifier
(uid)
to this is dead.
number number
for the
in
whencom-
contents
of the file. The segment summary block records this uid for each block in the segment; if the uid of a block does not match the uid currently stored in the inode map when the segment is cleaned, the block can be discarded immediately without examining the file’s inode. This approach to cleaning means that there is no free-block list or bitmap in Sprite. In addition to saving memory and disk space, the elimination of these
data
structures
also simplifies ACM
Transactions
crash
recovery.
on Computer
Systems,
If these Vol.
data
10, No.
structures
1, February
1992.
34
M. Rosenblum and J, K. Ousterhout
●
existed,
additional
restore
consistency
3.4
Segment
basic
(1) When only
many
(2) How
(3) Which
should
ment.
but live
files
call this
approach
Sprite
to the
fourth
LFS
the
file
system.
segments We
use
is the
The
remainder and how
including
of
overhead time
called
the the
and
data
overhead. mum
A
time
data
For
a log-structured
latency
are
total
number
of
those
bytes
ACM Transactions
One by
output
seglast
were
segments;
we
first
two
of the
number
the
of
a few tens of segthe number of clean
of bytes that
disk
means
that
for
for moved
represent
with
which
of
its
and
one-tenth new
no
there the
as
a
cleaning
with would
no
seek
mean
that
is no cleaning
of the
data;
cost
written,
expressed
were it
write
data
bandwidth
is perfect:
only
is
there
full
The
of new
cost
if
bandwidth
disk’s
rest
maxi-
of the
disk
or cleaning. large and
to and
analysis
policies. byte
write
writing
writing new
per
of 1.0
latency,
system
both
at
cost
they
of a log-structured
our
cleaning
The
written
third
the
experience
data.
required
full
used
In contrast,
performance
is busy
be
be
rotational file
negligible
the
the
in our
3 discusses
overheads.
10
values.
live
disk
A write of
the
the
would
actually
seeks,
the
at the
cost is
in
out?
they
new
when
important:
to compare
cost
could
be written
write
is spent
into
addressed
threshold
Section
of
that
latency.
bandwidth
time
the
segments
critically
to group
cleaning
the
could
are
for example
a single
value (typically at a time until
determine
of time
time
or rotational
new
by
at
that
ones
written
reads,
into
offers
cleaned
choice.
are
age together
cleaning
of the are
write
amount
all
multiple
they
blocks
the
of segments
that
to clean a term
or
cleaning
is the
best
of future
together
a threshold
choice
factors
average
for
segments
choice
when
not methodically starts
decisions
primary
are
are
at night,
another threshold value (typically 50– 100 clean segof Sprite LFS does not seem to be very performance
exact
policy
be
age sort.
segments surpasses ments). The overall sensitive
Segment
to be the
locality
of similar
clean segments drops below It cleans a few tens ments).
and
not
grouped the
is to sort
blocks
so far we have
policies.
and
must
choices
or only
more
the
An obvious
directory
same
possibility
and group
above
a time?
at
out
be
to enhance
modified
In our work
turns
blocks
issues
possible
Some
on disk;
be cleaned?
this
in the
Another
clean
to rearrange.
is to try
grouping
it
opportunities
the
possibility
structures
exhausted.
should
should
policy
at low priority,
data
segments
(4) How
execute?
to reorganize
fragmented,
most
cleaner
is nearly
segments
once, the more
to the
four
above,
in background
space
opportunity
an
described
segment
the
disk
to log changes
Policies
continuously
when
be needed
crashes.
mechanism
should
to run
it
after
Cleaning
the Given addressed:
would
code
from
data.
segments, for
seek
cleaning,
the This
on Computer Systems, Vol. 10, No 1, February
and
so the
disk
divided
cost
is
1992
rotational
write
by the
determined
cost
is
number by
the
The Design and Implementation utilization the
(the
steady
segment and
fraction
state, of new
writes
of data
the data
out
written.
and
O
