Write to Byte
Editorial Calendar

Categories
Previous Editions
Columns
Features
Audio



Resources
BYTE Forums
WebTools
Java Resources
Downloads
History Of Byte

BYTE Humor
Ian Shoales' Page

Print Archives
By Issue   By Topic

About Us
Byte Editorial Staff
Sales Staff
Privacy Policy




Search DDJ

DDJ Links

ARTICLES
SOURCE CODE
DEVSEARCHER
TECHNETCAST
BOOK REVIEWS
OP-EDS
COMMUNITY UNIVERSITY
MICROPROCESSOR RESOURCES
HISTORY OF COMPUTING
MAILINGLISTS




Serving With Linux

BYTE Magazine > Serving With Linux > 2000 > May

Extent-Based Allocation

(Journaling File Systems For Linux:  Page 3 of 7 )

In This Article
Journaling File Systems For Linux

How Does A File System Work?

Extent-Based Allocation

How Journaling File Systems Solve The Problem

Options For Linux

Source

Another Option
Extent-based file systems allocate disk blocks in large groups at a single time, which forces sequential allocation.

As a file is written, a large number of blocks are allocated, after which writes can occur in large groups or clusters of sequential blocks. File-system metadata is written when the file is first created. Subsequent writes within the first allocation extent of blocks do not require additional metadata writes (until the next extent is allocated).

This optimizes the disk-seek pattern, and the grouping of block writes into clusters allows the file system to issue larger physical disk writes to the storage device, saving the overhead of many small SCSI transfers

figure 1

Extent-based file systems provide good performance for sequential file access because of the sequential allocation policy and block clustering into larger writes. However, many of the benefits of extent-based file systems aren't leveraged when the file system is being used for random I/O. For example, if we want to read sequentially though an extent-based file, we only need to read the start block number and the length.

Then we can continue to read all of the data blocks in that extent, which means very little metadata read overhead is incurred in reading sequentially. In contrast, if we were to read a file in a random manner, we would need to look up the block address for the desired block for every data block read -- this is similar to what we would do with a block-based file system.

In ext2, several enhancements to the write code were implemented to delay writes long enough so that one large write could be performed in place of several smaller writes. This lets the file system issue one large write to the disk device, which is much more efficient than many smaller writes.

Similarly, the read paths were changed, such that if sequential access is being made to a file, a whole group of blocks are read in at once, effectively reading ahead into the file being accessed. The read enhancements also facilitated ext2 file systems to generate large read requests of the storage device in place of smaller requests, which eliminated the need to wait for many small individual disk I/Os for each read.

The size of the groups or "block clusters" being read and written is controlled by the file system a compile-time parameter. Cluster-size considerations are well beyond the scope of this article. Suffice it to say, they do have a major impact on file-system performance, in fact cluster size is at the center of a major dispute in file-systems design.

Extent-based file systems such as Veritas, and write-clustering systems such as ext2, are not so effective in applying these techniques; they choose to use 512-byte blocks rather than 1k blocks as their defaults. Ext2 reports a 20 percent speed-up when 4k rather than 1k blocks are used, but the authors of ext2 file systems advise the use of 1k blocks to avoid wasting space.


 Page 3 of 7 

BYTE Forums
Want to talk about this article?

 Serving With Linux
 


CMPnet


 

 

www4