Messages in this thread | | | Date | Tue, 08 Oct 2002 10:09:38 -0700 | From | Andrew Morton <> | Subject | Re: The reason to call it 3.0 is the desktop (was Re: [OT] 2.6 not 3.0 - (NUMA)) |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |