From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: cp --reflink of inline extent results in two DATA_EXTENT entries
Date: Wed, 23 Dec 2020 09:05:01 +0300 [thread overview]
Message-ID: <e7a7ddd7-1de7-3453-6398-3a5acc7f5e18@gmail.com> (raw)
In-Reply-To: <CAJCQCtQZJ8Jo8rX0BL51k5DmC1GEs21CyvmEOhoYDoY=g6XwCw@mail.gmail.com>
23.12.2020 06:48, Chris Murphy пишет:
> Hi,
>
> kernel is 5.10.2
>
> cp --reflink hi hi2
>
> This results in two EXTENT_DATA items with different offsets,
> therefore I think the data is duplicated in the leaf? Correct? Is it
> expected?
>
I'd say yes. Inline data is contained in EXTEND_DATA item and
EXTENT_DATA item cannot be shared by two different inodes (it is keyed
by inode number).
Even when cloning regular extent you will have two independent
EXTENT_DATA items pointing to the same physical extent.
> item 9 key (257 EXTENT_DATA 0) itemoff 15673 itemsize 53
> generation 435179 type 0 (inline)
> inline extent data size 32 ram_bytes 174 compression 3 (zstd)
>
> ...
> item 13 key (258 EXTENT_DATA 0) itemoff 15364 itemsize 53
> generation 435179 type 0 (inline)
> inline extent data size 32 ram_bytes 174 compression 3 (zstd)
>
>
> The entire file tree containing only these two files follows:
>
>
> file tree key (394 ROOT_ITEM 0)
> leaf 26442252288 items 14 free space 15014 generation 435212 owner 394
> leaf 26442252288 flags 0x1(WRITTEN) backref revision 1
> item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
> generation 435123 transid 435212 size 10 nbytes 0
> block group 0 mode 40755 links 1 uid 1000 gid 1000
> rdev 0
> sequence 5267 flags 0x0(none)
> atime 1608689569.708325037 (2020-12-22 19:12:49)
> ctime 1608694856.721370147 (2020-12-22 20:40:56)
> mtime 1608694856.721370147 (2020-12-22 20:40:56)
> otime 1608689569.708325037 (2020-12-22 19:12:49)
> item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
> index 0 namelen 2 name: ..
> item 2 key (256 DIR_ITEM 432062026) itemoff 16079 itemsize 32
> location key (257 INODE_ITEM 0) type FILE
> transid 435124 data_len 0 name_len 2
> name: hi
> item 3 key (256 DIR_ITEM 4216900732) itemoff 16046 itemsize 33
> location key (258 INODE_ITEM 0) type FILE
> transid 435196 data_len 0 name_len 3
> name: hi2
> item 4 key (256 DIR_INDEX 2) itemoff 16014 itemsize 32
> location key (257 INODE_ITEM 0) type FILE
> transid 435124 data_len 0 name_len 2
> name: hi
> item 5 key (256 DIR_INDEX 4) itemoff 15981 itemsize 33
> location key (258 INODE_ITEM 0) type FILE
> transid 435196 data_len 0 name_len 3
> name: hi2
> item 6 key (257 INODE_ITEM 0) itemoff 15821 itemsize 160
> generation 435124 transid 435212 size 174 nbytes 174
> block group 0 mode 100644 links 1 uid 1000 gid 1000
> rdev 0
> sequence 19 flags 0x0(none)
> atime 1608689574.394444809 (2020-12-22 19:12:54)
> ctime 1608694856.721370147 (2020-12-22 20:40:56)
> mtime 1608692923.231038818 (2020-12-22 20:08:43)
> otime 1608689574.394444809 (2020-12-22 19:12:54)
> item 7 key (257 INODE_REF 256) itemoff 15809 itemsize 12
> index 2 namelen 2 name: hi
> item 8 key (257 XATTR_ITEM 3817753667) itemoff 15726 itemsize 83
> location key (0 UNKNOWN.0 0) type XATTR
> transid 435124 data_len 37 name_len 16
> name: security.selinux
> data unconfined_u:object_r:unlabeled_t:s0
> item 9 key (257 EXTENT_DATA 0) itemoff 15673 itemsize 53
> generation 435179 type 0 (inline)
> inline extent data size 32 ram_bytes 174 compression 3 (zstd)
> item 10 key (258 INODE_ITEM 0) itemoff 15513 itemsize 160
> generation 435196 transid 435196 size 174 nbytes 174
> block group 0 mode 100644 links 1 uid 1000 gid 1000 rdev 0
> sequence 34 flags 0x0(none)
> atime 1608693921.97510335 (2020-12-22 20:25:21)
> ctime 1608693921.97510335 (2020-12-22 20:25:21)
> mtime 1608693921.97510335 (2020-12-22 20:25:21)
> otime 1608693921.97510335 (2020-12-22 20:25:21)
> item 11 key (258 INODE_REF 256) itemoff 15500 itemsize 13
> index 4 namelen 3 name: hi2
> item 12 key (258 XATTR_ITEM 3817753667) itemoff 15417 itemsize 83
> location key (0 UNKNOWN.0 0) type XATTR
> transid 435196 data_len 37 name_len 16
> name: security.selinux
> data unconfined_u:object_r:unlabeled_t:s0
> item 13 key (258 EXTENT_DATA 0) itemoff 15364 itemsize 53
> generation 435179 type 0 (inline)
> inline extent data size 32 ram_bytes 174 compression 3 (zstd)
> total bytes 31005392896
> bytes used 20153282560
>
>
>
next prev parent reply other threads:[~2020-12-23 6:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 3:48 cp --reflink of inline extent results in two DATA_EXTENT entries Chris Murphy
2020-12-23 6:05 ` Andrei Borzenkov [this message]
2020-12-24 0:19 ` Chris Murphy
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=e7a7ddd7-1de7-3453-6398-3a5acc7f5e18@gmail.com \
--to=arvidjaar@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox