e4defrag doesn't make an optimized defragmentation

Bug #911529 reported by Sworddragon on 2012-01-04
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
e2fsprogs (Ubuntu)
Undecided
Unassigned

Bug Description

I'm using Ubuntu 12.04 dev with e2fsprogs 1.42~WIP-2011-10-16-1ubuntu1. I wanted to defragment a big file (~9 GB) but sometimes e4defrag does nothing because it thinks the file is fully optimized (I guess). But a few seconds later, when I try to run defragmetation again, it decrease number of fragments. Here is an example:

~ $ e4defrag -v '/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi'
Result: [1/1]/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi: 100% extents: 71 -> 71 [ OK ]

The file wasn't defragmented at all, but immediately after this I used the same command again and here what I've got:

[1/1]/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi: 100% extents: 71 -> 69 [ OK ]

The file now was defragmented a little. I tried the command again:

[1/1]/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi: 100% extents: 69 -> 69 [ OK ]

The file wasn't defragmented but on the next try:

[1/1]/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi: 100% extents: 69 -> 68 [ OK ]

The file was defragmented. After the next try:

[1/1]/virtualbox/VirtualBox VMs/Ubuntu 32 Bit/Ubuntu 32 Bit.vdi: 100% extents: 68 -> 68 [ OK ]

The number of extents wasn't reduced but as the programm says the file was defragmented, and it needs couple minutes to run. I don't know why e4defrag is sometimes defragmenting an already previously defragmented file and sometimes not. And why aren't the extents reduced to the minimum size possible on the first try?

It think at least there must be an option to fully defrag. Or, for example, option to set minimum size of fragmented slice or something like that

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in e2fsprogs (Ubuntu):
status: New → Confirmed
Ken Sharp (kennybobs) on 2015-10-08
tags: added: i386 precise
GRbit (grbitt) on 2015-10-08
description: updated
Ken Sharp (kennybobs) wrote :

Precise again here. Some very very odd, and fairly useless, behaviour from e4defrag:

[292194/339739]/home/user/.bitcoin/blocks/blk00349.dat: 100% extents: 7 -> 3289 [ OK ]

$ sudo e4defrag -c /home/user/.bitcoin/blocks/blk00349.dat
<File> now/best size/ext
/home/user/.bitcoin/blocks/blk00349.dat 3289/1 24 KB

 Total/best extents 3289/1
 Average size per extent 24 KB
 Fragmentation score 83
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This file (/home/user/.bitcoin/blocks/blk00349.dat) needs defragmentation.
 Done.

$ e4defrag -v /home/user/.bitcoin/blocks/blk00349.dat
ext4 defragmentation for /home/user/.bitcoin/blocks/blk00349.dat
[1/1]/home/user/.bitcoin/blocks/blk00349.dat: 100% extents: 3289 -> 3289 [ OK ]
 Success: [1/1]

It turns out that this doesn't really make any sense anyway:

$ mv blk00349.dat blk00349.dat~
$ cp blk00349.dat~ blk00349.dat
$ sudo e4defrag -c blk00349.dat
<File> now/best size/ext
blk00349.dat 1/1 81920 KB

 Total/best extents 1/1
 Average size per extent 81920 KB
 Fragmentation score 0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This file (blk00349.dat) does not need defragmentation.
 Done.
$ e4defrag -v blk00349.dat
ext4 defragmentation for blk00349.dat
[1/1]blk00349.dat: 100% extents: 1 -> 1 [ OK ]
 Success: [1/1]
$ ll blk00349.dat*
-rw------- 1 user user 80M Oct 8 23:34 blk00349.dat
-rw------- 1 user user 80M Oct 8 18:25 blk00349.dat~

Unless this is a filesystem error? There haven't been any other errors on this filesystem so far....

$ e4defrag blk00349.dat~
ext4 defragmentation for blk00349.dat~
[1/1]blk00349.dat~: 100% [ OK ]
 Success: [1/1]

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers