Online defragmentation and ext4migrate
Hi Takashi san,
While doing online defragmentation do we move the blocks corresponding to extent index ? The reason why i am asking this is to understand the
usefulness of doing a ext4migrate followed by defrag. I understand that defragmentation in general will improve the performance. But with respect to ext4migrate we are not touching the data blocks. Instead we build the extent map and if that requires to have an extent index block then we allocate one. I am trying to understand what would be the performance impact of this and whether doing a defrag really improve the
performance.
Also looking at the version 0.4 I see that defrag ioctl only work if we have EXT4_EXTENTS_FL flag set. What are the plans for making defrag work with indirect block map inode ?
-aneesh
Quoted 5 lines · Aneesh Kumar K.V
The reason why i am asking this is to understand the usefulness of doing a ext4migrate followed by defrag.
[...]
Also looking at the version 0.4 I see that defrag ioctl only work if we haveEXT4_EXTENTS_FLflag set.
ext4migrate is necessary because the current ext4 defrag routines will only defragment files stored as extents. AFAIK, converting a file to extents does not allow the defrag routine to defragment it "better" than an indirect block map inode, but converting any file to extents has performance benefits regardless of whether it is later defragmented.
Quoted 2 lines
What are the plans for making defrag work
with indirect block map inode ?
I think there is a second set of patches to defragment non-extent files.
When I started investigating this topic, I would have preferred a defrag routine for indirect block map inodes since it would work with the filesystems that I and others are using right now. However, as I read more code and documentation, I'm beginning to warm up to extents.
A defragmentation routine makes files contiguous on disk. A better defragmentation routine intelligently locates data structures on the disk so that files and directories are placed to minimize latency and maximize throughput now, AND so that this will continue to happen in the future. Typically this means not only making files contiguous, but also consolidating free space at the end of the volume so that the block allocator can pick contiguous blocks for new files. An even better defragmentation routine knows how to balance the time lost to defragmentation with the performance gained from a defragmented filesystem. IMHO, this requires detailed knowledge of the layout of a file's blocks on the disk. Right now, we get this information by looping over the FIBMAP ioctl, which I understand can take quite a long time. But on an extent file there is a logical, high-performance mapping between the on-disk structures that keep track of which blocks belong to which files and the data returned by the as-yet-to-be-implemented FIEMAP ioctl, which could make defragging faster and more fun.
http://www.mail-archive.com/[email protected]/msg01434.html
Cheers,
Eric
Quoted 6 lines · Eric
A defragmentation routine makes files contiguous on disk. A better defragmentation routine intelligently locates data structures on the disk so that files and directories are placed to minimize latency and maximize throughput now, AND so that this will continue to happen in the future. Typically this means not only making files contiguous, but also consolidating free space at the end of the volume so that the block
It is not necessarily best to put free space at the END of the volume (that is very FAT-centric) but it does make sense to consolidate free space within each block group.
Quoted 6 lines
But on an extent file there is a logical, high-performance mapping between the on-disk structures that keep track of which blocks belong to which files and the data returned by the as-yet-to-be-implemented FIEMAP ioctl, which could make defragging faster and more fun.
Yeah, I wish I had time to finish working on this.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
Quoted 13 lines · Eric
Quoted 5 lines · Aneesh Kumar K.V
The reason why i am asking this is to understand the usefulness of doing a ext4migrate followed by defrag.
[...]
Also looking at the version 0.4 I see that defrag ioctl only work if we haveEXT4_EXTENTS_FLflag set.ext4migrate is necessary because the current ext4 defrag routines will only defragment files stored as extents. AFAIK, converting a file to extents does not allow the defrag routine to defragment it "better" than an indirect block map inode, but converting any file to extents has performance benefits regardless of whether it is later defragmented.
Quoted 6 lines
Quoted 2 lines
What are the plans for making defrag work
with indirect block map inode ?I think there is a second set of patches to defragment non-extent files.
I was looking at this and didn't find the changes needed to defrag the non extent files.
http://www.mail-archive.com/[email protected]/msg01522.html
Quoted 6 lines
An even better
defragmentation routine knows how to balance the time lost to defragmentation with the performance gained from a defragmented filesystem. IMHO, this requires detailed knowledge of the layout of a file's blocks on the disk. Right now, we get this information by looping over the FIBMAP ioctl, which I understand can take quite a long time.
With the takashi's code we use ext4_ext_alloc_blocks and see if the number of extents that we got is less than the number of extents that we have with the original file that we intent to defrag. I am not sure an ioctl is involved here.
Well the intent of my mail was to find the advantage of doing an online migration.
If we are not relocating the blocks corresponding to extent index then doing a online migration doesn't bring any specific performance bonus.
But yes i agree that there is a performance impact with defrag by moving the data
blocks closer.
-aneesh
Quoted 17 lines · Eric
Quoted 16 lines · Aneesh Kumar K.V
Quoted 5 lines
The reason why i am asking this is to understand the usefulness of doing a ext4migrate followed by defrag.
[...]
Also looking at the version 0.4 I see that defrag ioctl only work if we haveEXT4_EXTENTS_FLflag set.ext4migrate is necessary because the current ext4 defrag routines will only defragment files stored as extents. AFAIK, converting a file to extents does not allow the defrag routine to defragment it "better" than an indirect block map inode, but converting any file to extents has performance benefits regardless of whether it is later defragmented.
Quoted 2 lines
What are the plans for making defrag work
with indirect block map inode ?
Quoted 8 lines
Quoted 3 lines
I think there is a second set of patches to defragment non-extent files.
I was looking at this and didn't find the changes needed to defrag the non extent files.
I've written a patch that defragments non-extent files but after
discussion with XFS guys I've decided that the interfaces should be made more generic, so that XFS and other filesystems can use them too...
Honza
Signature · 2 lines
Jan Kara <[email protected]> SuSE CR Labs
Hi Aneesh san,
Quoted 2 lines
While doing online defragmentation do we move the blocks corresponding to extent index ? The reason why i am asking this is to understand the
usefulness of doing a ext4migrate followed by defrag. I understand that defragmentation in general will improve the performance. But with respect to ext4migrate we are not touching the data blocks. Instead we build the extent map and if that requires to have an extent index block then we allocate one. I am trying to understand what would be the performance impact of this and whether doing a defrag really improve the performance.
I think converting a file to extents has the benefit for the performance of block searching. If we want to improve also the performance of reading file data, we have to run the defrag after that.
Quoted 1 line
Also looking at the version 0.4 I see that defrag ioctl only work if we have
EXT4_EXTENTS_FLflag set. What are the plans for making defrag work with indirect block map inode ?
Unfortunately, my defrag doesn't support an indirect block file. But we can reduce fragments in the file with the defrag just after ext4migrate.
In my opinion, to keep the ioctl simple and small is very important for ease of maintenance. So I would rather not support indirect block files in the ioctl.
Instead, I can add the call of the migration ioctl to my defrag tool in order to defragment indirect block files. How do you think of it?
Cheers, Takashi
Hello,
Quoted 9 lines
Quoted 8 lines
While doing online defragmentation do we move the blocks corresponding to extent index ? The reason why i am asking this is to understand the usefulness of doing a ext4migrate followed by defrag. I understand that defragmentation in general will improve the performance. But with respect to ext4migrate we are not touching the data blocks. Instead we build the extent map and if that requires to have an extent index block then we allocate one. I am trying to understand what would be the performance impact of this and whether doing a defrag really improve the performance.
Quoted 3 lines
I think converting a file to extents has the benefit for the performance of block searching. If we want to improve also the performance of reading file data, we have to run the defrag after that.
Yes. On the other hand I believe that some people would like to use
defragmentation but stay with ext3. For them conversion to extents is no-go.
Quoted 8 lines
Quoted 3 lines
Also looking at the version 0.4 I see that defrag ioctl only work if we have
EXT4_EXTENTS_FLflag set. What are the plans for making defrag work with indirect block map inode ?Unfortunately, my defrag doesn't support an indirect block file. But we can reduce fragments in the file with the defrag just after ext4migrate.
Quoted 5 lines
In my opinion, to keep the ioctl simple and small is very important for ease of maintenance. So I would rather not support indirect block files in the ioctl. Instead, I can add the call of the migration ioctl to my defrag tool in order to defragment indirect block files. How do you think of it?
Yes that could be useful but I don't think it's a complete solution
for people that don't want to migrate.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SuSE CR Labs
Quoted 7 lines · Jan Kara
Yes. On the other hand I believe that some people would like to use
defragmentation but stay with ext3. For them conversion to extents is no-go.
[...]
I've written a patch that defragments non-extent files but after
discussion with XFS guys I've decided that the interfaces should be made more generic, so that XFS and other filesystems can use them too...
I see no reason why the ioctl to convert a file to extents and then defragment it should be different from the ioctl to defragment a non-extent file.
After all, whether a file's blocks are tracked as lists of blocks or a set of extents is just bookkeeping, right? The set of data blocks that make up the file and their order is the same regardless of whether the extent flag is set in the inode.
If the user is running the ext2/3 driver or the ext4 driver with the noextents option, just defragment the file. If the user is running ext4 without the noextents option, convert to extents and then defragment.
The only problem that I can think of is that defragmenting metadata (including indirect block and/or whatever the equivalent is in extent-land) presumably has performance benefits too, so maybe a defragmenter in userspace would want to have some knowledge/control over this process.
Cheers,
Eric
Quoted 8 lines · Jan Kara
Quoted 7 lines
Yes. On the other hand I believe that some people would like to use
defragmentation but stay with ext3. For them conversion to extents is no-go.
[...]
I've written a patch that defragments non-extent files but after
discussion with XFS guys I've decided that the interfaces should be made more generic, so that XFS and other filesystems can use them too...
Quoted 8 lines
I see no reason why the ioctl to convert a file to extents and then defragment it should be different from the ioctl to defragment a non-extent file.
After all, whether a file's blocks are tracked as lists of blocks or a set of extents is just bookkeeping, right? The set of data blocks that make up the file and their order is the same regardless of whether the extent flag is set in the inode.
I agree that at least part of the interface should
be independent on the particular representation of data references - especially because I want it to be useful for more filesystems than just ext2/3/4. Currently I think that defragmenting data blocks itself can have fs-independent interface. Of course, when you decide to defragment metadata (i.e. indirect blocks, inodes, etc.) you have to have fs-specific interfaces, probably ioctls...
Quoted 3 lines
If the user is running the ext2/3 driver or the ext4 driver with the noextents option, just defragment the file. If the user is running ext4 without the noextents option, convert to extents and then defragment.
Defragmentation ioctl definitely should not touch the way the file is
represented. I.e. if the file uses indirect blocks it should use indirect blocks after defragmentation. If it uses extents, it should use extents afterwards too. It should be the userspace utility which decides whether the file should be converted or not and uses appropriate call for that...
Quoted 5 lines
The only problem that I can think of is that defragmenting metadata (including indirect block and/or whatever the equivalent is in extent-land) presumably has performance benefits too, so maybe a defragmenter in userspace would want to have some knowledge/control over this process.
Yes, it has measurable benefit (especially for indirect blocks) so
eventually we should do it.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SuSE CR Labs
Quoted 9 lines · Takashi Sato
Hi Aneesh san,
In my opinion, to keep the ioctl simple and small is very important for ease of maintenance. So I would rather not support indirect block files in the ioctl.
Instead, I can add the call of the migration ioctl to my defrag tool in order to defragment indirect block files. How do you think of it?
That should be fine. So i will start moving the ext4migrate code as a ext4 ioctl and later will send you a patch to the defrag tool that will migrate and defrag.
-aneesh
Hi,
Quoted 8 lines
Quoted 6 lines
In my opinion, to keep the ioctl simple and small is very important for ease of maintenance. So I would rather not support indirect block files in the ioctl.
Instead, I can add the call of the migration ioctl to my defrag tool in order to defragment indirect block files. How do you think of it?That should be fine. So i will start moving the ext4migrate code as a ext4 ioctl and later will send you a patch to the defrag tool that will migrate and defrag.
OK. I am looking forward to your patch.
Cheers, Takashi