* cp --reflink of inline extent results in two DATA_EXTENT entries
@ 2020-12-23 3:48 Chris Murphy
2020-12-23 6:05 ` Andrei Borzenkov
0 siblings, 1 reply; 3+ messages in thread
From: Chris Murphy @ 2020-12-23 3:48 UTC (permalink / raw)
To: Btrfs BTRFS
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?
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
--
Chris Murphy
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: cp --reflink of inline extent results in two DATA_EXTENT entries
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
2020-12-24 0:19 ` Chris Murphy
0 siblings, 1 reply; 3+ messages in thread
From: Andrei Borzenkov @ 2020-12-23 6:05 UTC (permalink / raw)
To: Chris Murphy, Btrfs BTRFS
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
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cp --reflink of inline extent results in two DATA_EXTENT entries
2020-12-23 6:05 ` Andrei Borzenkov
@ 2020-12-24 0:19 ` Chris Murphy
0 siblings, 0 replies; 3+ messages in thread
From: Chris Murphy @ 2020-12-24 0:19 UTC (permalink / raw)
To: Andrei Borzenkov; +Cc: Chris Murphy, Btrfs BTRFS
On Tue, Dec 22, 2020 at 11:05 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>
> 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.
Thanks.
I saw this commit a long time ago and sorta just figured it meant
maybe inline extents would be cloned within a given leaf.
05a5a7621ce6
Btrfs: implement full reflink support for inline extents
But I only just now read the commit message, and it reads like cloning
now will be handled without error. It's not saying that it results in
shared inline data extents.
--
Chris Murphy
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-12-24 0:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2020-12-24 0:19 ` Chris Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox