GNU bug report logs - #8001
cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8001 in the body.
You can then email your comments to 8001 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: bug-coreutils <at> gnu.org
Subject: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)
Date: Mon, 7 Feb 2011 22:53:26 -0500

[Message part 1 (text/plain, inline)]

after upgrading from coreutils 8.9 to 8.10, the sparse handling in cp is 
silently breaking on btrfs filesystems with the compressed option enabled.  
using --sparse=never works fine, but "auto" or "always" tend to fail.  the 
cp/fiemap-2 test catches the issue nicely.

to reproduce (i'm using linux-2.6.37):
file=btrfs.img
mntp=/mnt/tmp/
dd if=/dev/zero of=$file bs=1M count=0 seek=1024
mkfs.btrfs $file 
mount -t btrfs -o compress $file $mntp
cd $mntp
tar xf ~/coreutils-8.10.tar.xz
cd coreutils-8.10/tests
./cp/fiemap-2

and this last test shows:
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/loop0   btrfs     1048576     20420    377028   6% /mnt/tmp
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.7598e-05 s, 0.0 kB/s
k k2 differ: byte 1, line 1
255+0 records in
255+0 records out
261120 bytes (261 kB) copied, 0.00310926 s, 84.0 MB/s
-mike

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.org
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Wed, 09 Feb 2011 10:57:14 +0000

On 08/02/11 03:53, Mike Frysinger wrote:
> after upgrading from coreutils 8.9 to 8.10, the sparse handling in cp is 
> silently breaking on btrfs filesystems with the compressed option enabled.  
> using --sparse=never works fine, but "auto" or "always" tend to fail.  the 
> cp/fiemap-2 test catches the issue nicely.
> 
> to reproduce (i'm using linux-2.6.37):
> file=btrfs.img
> mntp=/mnt/tmp/
> dd if=/dev/zero of=$file bs=1M count=0 seek=1024
> mkfs.btrfs $file 
> mount -t btrfs -o compress $file $mntp
> cd $mntp
> tar xf ~/coreutils-8.10.tar.xz
> cd coreutils-8.10/tests
> ./cp/fiemap-2
> 
> and this last test shows:
> Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> /dev/loop0   btrfs     1048576     20420    377028   6% /mnt/tmp
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 2.7598e-05 s, 0.0 kB/s
> k k2 differ: byte 1, line 1

Eek.

That doesn't trigger here (2.6.35.10-72.fc14.i686)
because I guess this kernel doesn't honor the compress attribute:

dd if=/dev/zero of=test.size count=1000
# du -B512 test.size
1000    test.size

But on a general note, we may read more (or possibly less)
than is stored in the extent. So how to detect that?
I suppose one could use lseek() to get the current position
and see if it's ext_start + ext_length, otherwise adjust accordingly.
That would add a little overhead though.
I also notice the FIEMAP_EXTENT_DATA_ENCRYPTED and FIEMAP_EXTENT_ENCODED
flags, which could mean we only need to handle these extents specially.
Does `filefrag -v` show those for you? I see nothing here.

I don't suppose there is any facility to read the raw data
to also avoid decompressing and compressing again (sendfile, mmap?).

cheers,
Pádraig.

Message #11 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Marti Raudsepp <marti <at> juffo.org>
Cc: btrfs hackers <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.org,
	Josef Bacik <josef <at> redhat.com>, Chris Mason <chris.mason <at> oracle.com>,
	Kernel hackers <linux-kernel <at> vger.kernel.org>
Subject: Re: btrfs: compression breaks cp and cross-FS mv, FS_IOC_FIEMAP bug?
Date: Tue, 15 Feb 2011 11:30:38 +0000

On 14/02/11 17:58, Marti Raudsepp wrote:
> On Mon, Feb 14, 2011 at 17:01, Chris Mason <chris.mason <at> oracle.com> wrote:
>> Or, it could just be delalloc ;)
> 
> I suspect delalloc. After creating the file, filefrag reports "1
> extent found", but for some reason it doesn't actually print out
> details of the extent.

That's a bug in `filefrag -v` that I noticed independently yesterday.
Without -v it will correctly report 0 extents.
I've already suggested a patch to fix upstream.

> After a "sync" call, the extent appears and "cp" starts working as expected:

About that sync.
I've noticed on ext4 loop back at least (and I suspect BTRFS is the same)
that specifying FIEMAP_FLAG_SYNC (which cp does) is ineffective.
I worked around this for cp tests by explicitly syncing with:
dd if=/dev/null of=foo conv=notrunc,fdatasync

> % rm -f foo bar
> % echo foo > foo
> % sync
> % filefrag -v foo
> Filesystem type is: 9123683e
> File size of foo is 4 (1 block, blocksize 4096)
>  ext logical physical expected length flags
>    0       0        0            4096 not_aligned,inline,eof
> foo: 1 extent found
> % cp foo bar
> % hexdump bar
> 0000000 6f66 0a6f
> 0000004

OK that's fine for normal files.
cp (from coreutils >= 8.10) may still do the wrong thing
as it currently ignores FIEMAP_EXTENT_DATA_ENCRYPTED and FIEMAP_EXTENT_ENCODED
as I've already reported:
http://www.mail-archive.com/linux-btrfs <at> vger.kernel.org/msg08356.html
I'd appreciate some `filefrag -v` output from a large compressed file.

cheers,
Pádraig.

Message #14 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Josef Bacik <josef <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 8001 <at> debbugs.gnu.org, Kernel hackers <linux-kernel <at> vger.kernel.org>,
	Chris Mason <chris.mason <at> oracle.com>,
	Josef Bacik <josef <at> redhat.com>, Marti Raudsepp <marti <at> juffo.org>,
	btrfs hackers <linux-btrfs <at> vger.kernel.org>
Subject: Re: btrfs: compression breaks cp and cross-FS mv, FS_IOC_FIEMAP bug?
Date: Tue, 15 Feb 2011 08:18:50 -0500

On Tue, Feb 15, 2011 at 11:30:38AM +0000, Pádraig Brady wrote:
> On 14/02/11 17:58, Marti Raudsepp wrote:
> > On Mon, Feb 14, 2011 at 17:01, Chris Mason <chris.mason <at> oracle.com> wrote:
> >> Or, it could just be delalloc ;)
> > 
> > I suspect delalloc. After creating the file, filefrag reports "1
> > extent found", but for some reason it doesn't actually print out
> > details of the extent.
> 
> That's a bug in `filefrag -v` that I noticed independently yesterday.
> Without -v it will correctly report 0 extents.
> I've already suggested a patch to fix upstream.
> 
> > After a "sync" call, the extent appears and "cp" starts working as expected:
> 
> About that sync.
> I've noticed on ext4 loop back at least (and I suspect BTRFS is the same)
> that specifying FIEMAP_FLAG_SYNC (which cp does) is ineffective.
> I worked around this for cp tests by explicitly syncing with:
> dd if=/dev/null of=foo conv=notrunc,fdatasync
>

Well thats not good, thats all take care of in the generic code before it gets
to the fs, I'll take a look at that when I try and fix delalloc fiemap for
btrfs.  Thanks,

Josef 

Message #17 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.org
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Sat, 19 Feb 2011 13:28:40 -0500

[Message part 1 (text/plain, inline)]

based on other threads (which i havent been following too closely), did we 
settle on this being a btrfs bug ?
-mike

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.org
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Sat, 19 Feb 2011 23:22:15 +0000

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 ?
> -mike

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.

Also `filefrag -v` output for the file on
the compressed BTRFS file system would be helpful.

thanks,
Pádraig.

Message #23 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.org
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Sun, 20 Feb 2011 00:39:47 +0000

On 19/02/11 23:22, Pádraig Brady wrote:
> 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 ?
>> -mike
> 
> 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.
> 
> Also `filefrag -v` output for the file on
> the compressed BTRFS file system would be helpful.

Hmm I just tried the latest Fedora 15 live image
and was tripped up a bit by https://bugzilla.redhat.com/show_bug.c

Anyway it uses 2.6.38 rc4 and "compress" doesn't
seem to be implemented for BTRFS there?
Writing a file of zeros showed a normal disk usage,
and filefrag -v didn't report any flags for the extents.

In any case, cp/fiemap-2 passed on each of
about 100 runs, even without introducing
and syncs.

cheers,
Pádraig.

Message #26 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>, 8001 <at> debbugs.gnu.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

2011/2/19 Pádraig 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=1k seek=1 of=k count=255 < /dev/zero || framework_failure_

+filefrag -v k
+sync
+filefrag -v k
+
 # cp should detect the all-zero blocks and convert some of them to holes.
 # How many it detects/converts currently depends on io_blksize.
 # Currently, on my F14/ext4 desktop, this K starts off with size 256KiB,
 # (note that the K in the preceding test starts off with size 4KiB).
 # cp from coreutils-8.9 with --sparse=always reduces the size to 32KiB.
 cp --sparse=always k k2 || fail=1
+
+sync
+
 test $(stat -c %b k2) -lt $(stat -c %b k) || fail=1

 Exit $fail

> Also `filefrag -v` output for the file on
> the compressed BTRFS file system would be helpful.

the output from the aforementioned patch:
...
+ dd bs=1k seek=1 of=k count=255
255+0 records in
255+0 records out
261120 bytes (261 kB) copied, 0.00313737 s, 83.2 MB/s
+ filefrag -v k
Filesystem type is: 9123683e
File size of k is 262144 (64 blocks, blocksize 4096)
 ext logical physical expected length flags
k: 1 extent found
+ sync
+ filefrag -v k
Filesystem type is: 9123683e
File 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
...
-mike

Message #29 received at 8001 <at> debbugs.gnu.org (full text, mbox):

From: Chris Mason <chris.mason <at> oracle.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: Pádraig Brady <p <at> draigbrady.com>,
	BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>,
	8001 <8001 <at> debbugs.gnu.org>
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Tue, 22 Feb 2011 22:31:19 -0500

Excerpts from Mike Frysinger's message of 2011-02-19 19:53:18 -0500:
> 2011/2/19 Pádraig 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:

I've got a fix for this on the btrfs side in testing.  It is definitely
a btrfs bug.

-chris

Message #34 received at 8001-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Chris Mason <chris.mason <at> oracle.com>, 8001-done <at> debbugs.gnu.org
Cc: Mike Frysinger <vapier <at> gentoo.org>,
	BTRFS MAILING LIST <linux-btrfs <at> vger.kernel.org>
Subject: Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs
	(cp/fiemap-2)
Date: Wed, 23 Feb 2011 09:49:55 +0000

On 23/02/11 03:31, Chris Mason wrote:
> I've got a fix for this on the btrfs side in testing.  It is definitely
> a btrfs bug.

[resend]

Cool.
I'm closing this ticket, so.

Interesting I didn't notice this with kernel-2.6.38-0.rc4.git0.2.fc15.i686
(with a 1G loop back BTRFS on ext4)

I'd appreciate a link to the fix at some stage.
If we know what's going on exactly we might be
able to know how widespread the issue is and
whether we could work around it in `cp`.

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.