linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: dave@jikos.cz
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 2/2] Btrfs: snapshot-aware defrag
Date: Tue, 11 Sep 2012 23:00:53 +0800	[thread overview]
Message-ID: <504F5225.6050404@oracle.com> (raw)
In-Reply-To: <20120910234911.GU17430@twin.jikos.cz>

On 09/11/2012 07:49 AM, David Sterba wrote:
> On Thu, Sep 06, 2012 at 09:10:52AM +0800, Liu Bo wrote:
>> This comes from one of btrfs's project ideas,
>> As we defragment files, we break any sharing from other snapshots.
>> The balancing code will preserve the sharing, and defrag needs to grow this
>> as well.
>>
>> Now we're able to fill the blank with this patch, in which we make full use of
>> backref walking stuff.
>>
>> Here is the basic idea,
>> o  set the writeback ranges started by defragment with flag EXTENT_DEFRAG
>> o  at endio, after we finish updating fs tree, we use backref walking to find
>>    all parents of the ranges and re-link them with the new COWed file layout by
>>    adding corresponding backrefs.
>>
>> Original-Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> 
> This is a non-standard tag, I think Li will not object against
> Signed-off-by as his original submission covers most of this patch. And
> more S-O-B lines is allowed and understood.
> 

So I googled for a standard tag 'Original-patch-by' suggested by Tejun Heo, is it ok?

>> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
>> ---
>> v2: rebase against the latest btrfs-repo
>>

>> +		if (btrfs_file_extent_disk_bytenr(leaf, fi) == new->bytenr &&
>> +		    btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_REG &&
>> +		    !btrfs_file_extent_compression(leaf, fi) &&
>> +		    !btrfs_file_extent_encryption(leaf, fi) &&
>> +		    !btrfs_file_extent_other_encoding(leaf, fi) &&
>> +		    extent_len + found_key.offset == start) {
> 
> so no cow-aware defrag for compressed files?
> 

hmm, it just disable merging adjacent compressed extents, and it may leave some space to improve.

> 
> general notes:
> * the error handling or reporting could be improved, I wouldn't mind the
>   more WARN_ONs or BUG_ONs for testing purposes, but for a finalized
>   versiont the practice of transaction abort or at least an attempt to
>   minimize number of BUG_ONs should be done
> * I didn't review the math over the extent lengths and starts
> 
> ohterwise ok, passed 1st round :)
> 
> david
> 

Will address the comments in a new version.

I'd say a huge thank you for reviewing this :)

thanks,
liubo


      reply	other threads:[~2012-09-11 15:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-06  1:10 [PATCH v2 1/2] Btrfs: use flag EXTENT_DEFRAG for snapshot-aware defrag Liu Bo
2012-09-06  1:10 ` [PATCH v2 2/2] Btrfs: " Liu Bo
2012-09-06 13:11   ` Josef Bacik
2012-09-06 14:13     ` Liu Bo
2012-09-06 14:26     ` Liu Bo
2012-09-10 23:49   ` David Sterba
2012-09-11 15:00     ` Liu Bo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=504F5225.6050404@oracle.com \
    --to=bo.li.liu@oracle.com \
    --cc=dave@jikos.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).