2010/8/26 Kazuya Mio <k-mio@xxxxxxxxxxxxx>: > Hi Andreas, > Thanks for the comments. > > 2010/08/25 21:00, andreas@xxxxxxxxxx wrote: >> Is there a reason why the offset of the original file and the donor file >> must be the same? > > e4defrag creates a donor file whose size is the same of the original file by > fallocate. There is a possibility that the original file will be corrupted > after moving an extent if the offset of the original file and the donor file > are different. So they are checked in the kernel space, but it may be > unnecessary from the point of view of the ioctl. > >> As i can see the patch for relevant file defragmentation in e4defrag >> supports only directories. May it be possible to select any desired file? > > That's interesting. I came up with the new interface of e4defrag -r. > What do you think the following implementation idea? > > Usage: e4defrag -r directory...| device... > e4defrag -r base_file move_file... <--- new > > 1. Defrag base_file to reduce fragmentation of extents (call EXT4_IOC_MOVE_EXT) > 2. Preallocate physical blocks near the data blocks of base_file > 3. Move move_file's extents to the blocks that are allocated by (2). > 4. Repeat (2) and (3) for all files specified as move_file > > Regards, > Kazuya Mio I suspect the original idea would work better because it is more likely to pack the libs / files into perfectly contiguous block ranges. I too have never understood why the donor offsets have to match the original offsets, although I had previously assumed the issue could be worked around via making the donor file sparse and only have the block range of interest allocated. This use case is a specific example of where it would be beneficial to eliminate that artificial limitation. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
