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
prev parent 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).