From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: "Yan, Zheng " <yanzheng@21cn.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Chris Mason <chris.mason@oracle.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 12/12] Btrfs: Fix file clone when source offset is not 0
Date: Thu, 02 Feb 2012 22:00:30 +0100 [thread overview]
Message-ID: <4F2AF96E.3040201@jan-o-sch.net> (raw)
In-Reply-To: <CAAM7YAkWj2Avf8zA_Vb-QC-YL8wOBuPPXOEENkSB9vmx5vbEHA@mail.gmail.com>
On 02.02.2012 05:31, Yan, Zheng wrote:
> On Mon, Jan 30, 2012 at 6:03 PM, Jan Schmidt <list.btrfs@jan-o-sch.net> wrote:
>> On 30.01.2012 07:33, Li Zefan wrote:
>>> Jan Schmidt wrote:
>>>> [...]
>>> Unfortunately this is expected. The calculation is:
>>>
>>> extent_item.extent_data_ref.offset = file_pos - file_extent.extent_offset
>>>
>>> so you may get negative offset.
>>
>> I see where the negative offset comes from. But what can this offset be
>> used for?
>>
>
> The offset in backref isn't equal to the offset of the file extent,
> it's just a hint for searching
> file extents
I see. Thanks for clarifying.
And, Li: Thanks for bringing the old thread back to my mind.
Nevertheless, that still seems quite a strange choice to me. Is there a
deep sense behind it that is deeper than I'm currently looking?
-Jan
next prev parent reply other threads:[~2012-02-02 21:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-27 8:42 [PATCH 00/12] Btrfs: Some bug fixes Li Zefan
2011-01-27 8:42 ` [PATCH 01/12] btrfs: Fix threshold calculation for block groups smaller than 1GB Li Zefan
2011-01-27 8:42 ` [PATCH 02/12] btrfs: Add helper function free_bitmap() Li Zefan
2011-01-27 8:43 ` [PATCH 03/12] btrfs: Free fully occupied bitmap in cluster Li Zefan
2011-01-27 8:43 ` [PATCH 04/12] btrfs: Update stats when allocating from a cluster Li Zefan
2011-01-27 8:44 ` [PATCH 05/12] btrfs: Add a helper try_merge_free_space() Li Zefan
2011-01-27 8:44 ` [PATCH 06/12] btrfs: Check mergeable free space when removing a cluster Li Zefan
2011-01-27 8:44 ` [PATCH 07/12] Btrfs: Fix memory leak at umount Li Zefan
2011-01-27 8:44 ` [PATCH 08/12] Btrfs: Fix memory leak on finding existing super Li Zefan
2011-01-27 8:45 ` [PATCH 09/12] Btrfs: Free correct pointer after using strsep Li Zefan
2011-01-27 8:45 ` [PATCH 10/12] Btrfs: Don't return acl info when mounting with noacl option Li Zefan
2011-01-27 8:45 ` [PATCH 11/12] Btrfs: Fix memory leak in writepage fixup work Li Zefan
2011-01-27 8:46 ` [PATCH 12/12] Btrfs: Fix file clone when source offset is not 0 Li Zefan
2012-01-26 13:52 ` Jan Schmidt
2012-01-26 16:17 ` David Sterba
2012-01-30 6:33 ` Li Zefan
2012-01-30 10:03 ` Jan Schmidt
2012-02-01 9:44 ` Li Zefan
2012-02-02 4:31 ` Yan, Zheng
2012-02-02 21:00 ` Jan Schmidt [this message]
2012-02-02 4:25 ` Yan, Zheng
2012-02-02 5:31 ` Li Zefan
2012-02-02 6:44 ` Yan, Zheng
2011-01-30 23:48 ` [PATCH 00/12] Btrfs: Some bug fixes Chris Mason
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=4F2AF96E.3040201@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=yanzheng@21cn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.