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 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users