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

Re: searching for ext3 defrag/file move program



On Thursday 03 March 2005 17:10, Theodore Ts'o wrote:
> 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.
Ok, given that's it not easily possible.
How about a program that moves just the file's data to the start of the disk?
AFAIK it doesn't work just to copy the files - you won't get them copied to a 
defined place, they'll end up in the various groups.

Any idea how to make the startup process faster? 


Regards,

Phil


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