Online resizing of ext3 filesystems {shrink}

[Bill Rugolsky Jr.]

On Mon, Jan 09, 2006 at 10:42:14AM -0500, Jeff Spaleta wrote:
> Doesn't this issue of how ext3 sprinkles data around the disk also
> impact the underlying limitations on speed of bootup and desktop
> initiation? Not that I care about bootup speed issue, because I really
> really don't.  But I've been told that diskseek is the large
> bottleneck. Wouldn't a defragmenter signficantly help with diskseek
> related speed limitations?

A DOS/Windows defragmenter [caveat: last I used one was in the early
1990s] generally stuffs files into contiguous locations on disk without
much regard for their interrelationship.   What we need is a (background)
disk optimizer, that will layout multiple related files in the order of their
access.

For a long while Arjan had a patch in the kernel SRPM, turned off
by default, that output a list of files as they were opened on startup.
I believe that list formed the basis for the readahead service file list, but
I don't know the details.  [I haven't followed the subsequent work involving
bootchart.]

A motivated student could certainly move the ball forward with a senior
thesis, Google SoC, etc., project.  In a certain sense, the problem is
not unlike swap pagein, and similar (e.g., Markov) methods might apply,
the problem being one of where to record the statistics, and then
resurrecting one of the tools to reorganize the filesystem layout.

Andrew Morton seemed to very much like the idea of background best-effort
filesystem layout optimization back when it was discussed.  Which is one
way of saying, "if you build it, he will merge ..."

Regards,

	Bill Rugolsky