From: Mike Frysinger <vapier@gentoo.org>
To: "Pádraig Brady" <P@draigbrady.com>
Cc: 8001@debbugs.gnu.org, BTRFS MAILING LIST <linux-btrfs@vger.kernel.org>
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)
Date: Sat, 19 Feb 2011 19:53:18 -0500 [thread overview]
Message-ID: <AANLkTi=4x+RzqZRKVCreWy67eOUSocjA4c_N+9aEHeG9@mail.gmail.com> (raw)
In-Reply-To: <4D6050A7.5090407@draigBrady.com>
2011/2/19 P=E1draig Brady:
> On 19/02/11 18:28, Mike Frysinger wrote:
>> based on other threads (which i havent been following too closely), =
did we
>> settle on this being a btrfs bug ?
>
> Nope, cp 8.10 is not absolved yet.
> It may be btrfs not honoring FIEMAP_FLAG_SYNC,
> and/or it may be cp needing to handle FIEMAP_EXTENT_ENCODED
> specially.
>
> It would help if you ran `sync` before the copy,
> to exclude that as a possible issue.
makes no difference after applying this patch:
--- coreutils-8.10/tests/cp/fiemap-2
+++ coreutils-8.10/tests/cp/fiemap-2
@@ -43,12 +43,19 @@
printf x > k || framework_failure_
dd bs=3D1k seek=3D1 of=3Dk count=3D255 < /dev/zero || framework_failur=
e_
+filefrag -v k
+sync
+filefrag -v k
+
# cp should detect the all-zero blocks and convert some of them to hol=
es.
# How many it detects/converts currently depends on io_blksize.
# Currently, on my F14/ext4 desktop, this K starts off with size 256Ki=
B,
# (note that the K in the preceding test starts off with size 4KiB).
# cp from coreutils-8.9 with --sparse=3Dalways reduces the size to 32K=
iB.
cp --sparse=3Dalways k k2 || fail=3D1
+
+sync
+
test $(stat -c %b k2) -lt $(stat -c %b k) || fail=3D1
Exit $fail
> Also `filefrag -v` output for the file on
> the compressed BTRFS file system would be helpful.
the output from the aforementioned patch:
=2E..
+ dd bs=3D1k seek=3D1 of=3Dk count=3D255
255+0 records in
255+0 records out
261120 bytes (261 kB) copied, 0.00313737 s, 83.2 MB/s
+ filefrag -v k
=46ilesystem type is: 9123683e
=46ile size of k is 262144 (64 blocks, blocksize 4096)
ext logical physical expected length flags
k: 1 extent found
+ sync
+ filefrag -v k
=46ilesystem type is: 9123683e
=46ile size of k is 262144 (64 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 47917 32
1 32 47918 47948 32 eof
k: 2 extents found
=2E..
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-02-20 0:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201102072253.34476.vapier@gentoo.org>
2011-02-09 10:57 ` bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2) Pádraig Brady
2011-02-19 18:28 ` Mike Frysinger
2011-02-19 23:22 ` Pádraig Brady
2011-02-20 0:39 ` Pádraig Brady
2011-02-20 0:53 ` Mike Frysinger [this message]
2011-02-23 3:31 ` Chris Mason
2011-02-23 9:49 ` Pádraig Brady
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='AANLkTi=4x+RzqZRKVCreWy67eOUSocjA4c_N+9aEHeG9@mail.gmail.com' \
--to=vapier@gentoo.org \
--cc=8001@debbugs.gnu.org \
--cc=P@draigbrady.com \
--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).