荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: Lg (创造人生的传奇), 信区: Linux
标  题: Coming Soon to a File System Near You
发信站: BBS 荔园晨风站 (Sat Jan  8 14:12:11 2000), 站内信件

Coming Soon to a File System Near You! -
December 15th, 1999
   by Luke Groeninger

As Linux gets older, parts of it get older as well, with little
or no modification or updates. One of these components
is the ext2 file system. With the size of hard drives
quickly growing to far beyond what anyone ever
imagined four or five years ago would become
standard, ext2 was developed. The inherent limitations
of the ext2 file system were not apparent, but as newer,
faster hard drives with larger capacities appeared,
some of the kludges that went into the ext2 file system
have shown their ugly heads.

The fact that the ext2 file system has limitations is not a
secret. It is inefficient when dealing with large file system
sizes, it has a 2GB file limit, and relatively poor
performance. While for the average user this does not
matter much, in the middle and high-end server markets,
this makes a big difference. In such markets database
sizes are often beyond 2GB, and multiple drive arrays
can make for file systems in the terabyte range.
Performance degrades as the drive size goes up, and
large files are (of course) slower to access.

One of the major limitations come as a result of the
design of the file system driver, and as a result, the file
system as well. The ext2 file system was designed so
that in the case of a crash, it would be easy to determine
which data was lost. The easiest way of doing this is to
wait for the first writes to finish before the next ones are
given to the device driver. The "synchronous metadata
update" approach, as it is called, limits the amount of
data that is affected by a crash, and offers decent crash
recovery. The disadvantage to this is that it offers lower
average performance. Because it has to wait while the
previous request is finished before even buffering a
drive operation, its performance drops.

So how does one get around these limitations? A better
method of accessing the disk is through the use of a
"journaling," a technique that allows the drive to write the
data to disk using buffering. When a drive asks to
modify a block, it modifies a copy in the journal instead.
Only after the journal copy is written to the journal itself
will the data be written to the disk. This allows undoing of
changes to the file system (the new data in the journal
can be overwritten), or recreation of the new data in
case something goes wrong (copying the journal data
into place on the drive). This technique offers better
performance (data can be written sequentially into the
journal, then written to the disk later) and better crash
recovery.

Several projects are underway to develop a
replacement for the ext2 file system with the advantages
of a journaling file system. Three of them are highly
notable, as they have been developing rapidly to a
usable state, and all use journaling. These three are the
ReiserFS Balanced Tree File System, the SGI XFS File
System and the Ext3 File System. Each of these file
systems have unique features and development paths,
and could possibly be the successor to the ext2 file
system.

ReiserFS is quite possibly the farthest along in
development. Reported to be remarkably stable, it offers
a different method of holding the data on the drive by
using balanced trees to hold the file data as well as the
file names, as well as journaling support. These
features, combined with the fact that it was designed
from the ground up to be fast and efficient on large
drives and drive arrays make it a top-notch file system
for using on servers. The disadvantages that have been
reported come from compatibility problems between
releases, often requiring you to reformat the entire
partition just to use a new version. ReiserFS has been
released under the GPL, with some commercial
exceptions, and is currently for the Intel architecture only,
but may be ported later.

The open source release of SGI's XFS file system has
caused a lot of speculation in the developer community.
SGI, in probably one of the most interesting business
moves I have ever heard of, decided to support the
Linux community by releasing the source code to its file
system, working to help improve the Linux kernel, and
releasing a lot of its own proprietary code as open
source. The XFS file system is a full 64-bit journaling file
system that has been used on SGI's IRIX platform for
many years, and has been tested and debugged quite
thoroughly on IRIX. While still in beta release, the Linux
port of this file system has been making progress
rapidly.

The third file system is the ext3 file system, which is
designed to be an updated version of the ext2 file
system currently used on almost all Linux boxes today.
Currently still under development, this file system adds
journaling information to the metablock of the ext2 file
system, and aims for both backwards and forwards
compatibility. This file system is probably best
described as evolution of the ext2 file system, is
reportedly fairly unstable right now, and is probably the
farthest from being completed of the three file systems
mentioned here.

As these three file systems get closer to completion,
they will all offer comparable features and all will provide
better performance than the current ext2 file system. As
drive sizes and transfer rates increase, the demand for
a faster file system will increase. Any of these three
should do quite nicely, each offering slightly different
features and performance.

--
☆ 来源:.BBS 荔园晨风站 bbs.szu.edu.cn.[FROM: bbs@210.39.3.71]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店