[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: searching for ext3 defrag/file move program



On Wed, Mar 02, 2005 at 01:14:01PM +0100, Ph. Marek wrote:
> Hello everybody,
> 
> reading about the speed improvements possible with (on boot) preloaded files 
> (which should be continuous on disk) I searched for a ext3 defrag program.
> 
> I found an ext2 defrag program 
> (http://www.ibiblio.org/pub/Linux/system/filesystems/defrag-0.70.tar.gz, 
> available in debian as defrag) which would have an optimal feature (moving 
> files by a list) but refuses to work on ext3.
> 
> Is there a version which does ext3? Or has somebody a program which allows me 
> to move files on the disk?

The e2defrag program had some problems where it only worked on 1k
blocksizes, if I remember correctly.  It was also extremely dangerous
in that if it crashed or you had a system crash/powerfailure in middle
of the operation, your filesystem would be totally scrambled.
Therefore, the only safe way to use it was to do a full backup, and if
the system crashed, restore from the backup.  

Given that the filesystem had to be unmounted during the e2defrag
process, and combined with the fact that if you wanted to be safe, you
had to do a full backup of the data *anyway*, the time difference
between doing "backup; e2defrag; mke2fs and restore if your system
crashed" and "backup; mke2fs; restore" was such that it really wasn't
worth it.

Mainly, there hasn't been sufficient interest to write a (safe,
effective) ext2 defragger.  (There was one crazy person who didn't
believe me when I told him that an ext3 defragger couldn't be done
purely in userspace, until he banged his head against the wall enough
times, but that doesn't count.  :-) Instead there has been more
interest in tweaking algorithsm that try to avoid the fragmentation
problem in the first place --- for example, such as the Orlov
allocator that got introduced during Linux 2.5.  Another example is
the delayed allocation code plus the extent mapping extension that has
been currently discussed on ext2-devel.

There has been talk about writing a kernel extension which implements
a few safe, atomic operations, such as relocating a logical block #w
in inode #x from block #y to #z, and "here are all the pathnames that
point at inode #x, relocate that inode to be stored at location #y",
and then implementing the rest in userspace.  But it just hasn't risen
to the top of anyone's todo lists yet.

						- Ted


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]