Re: The reason to call it 3.0 is the desktop (was Re: [OT] 2.6 not 3.0 - (NUMA))

Andrew Morton
2002-10-08T17:04:06Z

jlnance@intrex.net wrote:
>
> On Mon, Oct 07, 2002 at 07:50:27PM -0700, Andrew Morton wrote:
>
> > I have the core code for ext3. It's at
> > http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.19-pre10/ext3-reloc-page.patch
> > I never tested it, but that's a formality ;)
> >
> > It offers a simple ioctl to reloate a single page's worth of blocks.
> > It's fully journalled and recoverable, pagecache coherent, etc.
> > But the userspace application which calls that ioctl hasn't been
> > written.
>
> Hi Andrew,
> I decided not to let the fact that I have never written any FS code
> stand in the way of making suggestions :-) :-)
> Do you think it would be better to make the defragmentation part of
> the normal operation of the FS rather than a seperate application. For
> example, if you did a fragmentation check/fix on the last close of a file
> you would know that coherency issues were not going to be important. It
> might also give you some way to determine which files were important to
> keep close together.
>

Well the initial approach was to put the minimum functionality
in-kernel and drive it all from userspace. I that proved to
be inadequate then the kernel-side might need to be grown.

I'd expect that a defrag would be a batch process which is done
during quiet times. Although one _could_ have a `defragd' which
ticks along all the time I suppose.

A defragmentation algorithm probably would not be a "per file" thing;
it would need to gather a fair amount of state about the fs, or
at least an individual block group before starting to shuffle things.