On Fri, Feb 8, 2013 at 8:53 AM, David Sterba <dsterba@xxxxxxx> wrote:
> On Thu, Feb 07, 2013 at 11:17:46PM -0600, Mitch Harder wrote:
>> On Thu, Feb 7, 2013 at 6:28 PM, David Sterba <dave@xxxxxxxx> wrote:
>> > On Thu, Feb 07, 2013 at 03:38:34PM -0600, Mitch Harder wrote:
>> >> --- a/fs/btrfs/relocation.c
>> >> +++ b/fs/btrfs/relocation.c
>> >> @@ -144,7 +144,7 @@ struct tree_block {
>> >> unsigned int key_ready:1;
>> >> };
>> >>
>> >> -#define MAX_EXTENTS 128
>> >> +#define MAX_EXTENTS 512
>> >
>> > Is this really related to compression? IIRC I've seen it only in context
>> > of batch work in reloc, but not anywhere near compression. (I may be
>> > wrong of course, just checking).
>> >
>>
>> When you defragment compressed extents, it will run through relocation.
>>
>> If autodefrag is enabled, I found most everything I touched was
>> running through relocation.
>
> AFAIK defragmentation runs through the writeback loop, blocks are marked
> dirty, delalloc tries to make them contiguous and then synced back to
> disk. Autodefrag uses the same loop, just affects newly written data.
>
>> It has been a while since I looked at the issue, but I think balancing
>> your data will also run through relocation.
>
> Balance does go through reloc for sure.
>
> From the commit that introduces MAX_EXTENTS it's imo quite clear that
> it's only a balance speedup:
>
> (0257bb82d21bedff26541bcf12f1461c23f9ed61)
> Btrfs: relocate file extents in clusters
>
> The extent relocation code copy file extents one by one when
> relocating data block group. This is inefficient if file
> extents are small. This patch makes the relocation code copy
> file extents in clusters. So we can can make better use of
> read-ahead.
In an earlier version of the patch, I had the changes to relocation.c
in a separate patch. But, I couldn't consistently attain the changed
maximum extent size unless I also addressed the issue with relocation.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
