[Ocfs2-tools-devel] [PATCH 4/4] Defrag the filesystem

[Joel Becker]

On Wed, Mar 17, 2010 at 08:29:19PM -0500, Goldwyn Rodrigues wrote:
> Algorithm:
> 1. Read all group descriptors and sort them with respect to block number
> 2. Read all inodes
> 3. For all group descriptors:
>    a. Find a hole in the bitmap
>    b. Find a extent rec which will best fit in the hole and has a
>       block number greater than the hole
>    c. Find the group descriptor corresponding to the found rec
>    d. Move the extent.
> 
> Limitations:
>  - Only zero depth files are victimized for move.
>  - Victim files can be spread across gds, making them inefficient
>    to read. can be made efficient by moving the rest of the file
>    even if it is not a perfect match

	This last point is kind of a disaster.  We can't tolerate
significant performance degradations.
	A better way to look at it is that there are two types of
defragmentation:

1. Making files more contiguous.  This means taking files of many small
   extents and making them consist of fewer, larger extents.  This is
   good for performance.
2. Making the whole disk more contiguous.  This means packing file data
   to one end of the disk so that free space is in large hunks.  This is
   good for future allocation of unfragmented files.

	Your algorithm attacks type 2.  However, it hurts type 1 because
it might make data hunks farther apart.
	There are other locality concerns.  Imagine a fragmented file.
It has an inode and 100 extents.  The inode and the data are near the
end of the disk.  Now your code moves the 100 extents to the front of
the disk.  Not only have you not improved type 1, the filesystem must
seek across the entire disk to update the inode and the data.

Joel

-- 

	f/8 and be there.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127