patch will allow degraded chunk to exist and fix the bug.
Thanks,
Qu
Original Message
Subject: Re: [PATCH 4/4] btrfs-progs: Add extra chunk item check to
avoid btrfs-progs crash.
From: WorMzy Tykashi wormzy.tyka...@gmail.com
To: David Sterba dste...@suse.cz, Qu Wenruo
quwen
Currently this test uses the system btrfs-image. If there isn't a
btrfs-image on $PATH, the test fails. The test should be using the
locally compiled btrfs-image, not the system one.
---
diff --git a/tests/fsck-tests/012-leaf-corruption/test.sh
b/tests/fsck-tests/012-leaf-corruption/test.sh
index
Hi David,
I've been watching the 3.19.x branch with interest, and noticed that
you've tagged rc1. Unfortunately, I think I've found a few problems
with it. I will try to explain here:
For the record, I'm building using devtools (a set of clean chroot
build scripts) on an up-to-date Arch Linux
On 19 December 2014 at 13:48, David Sterba dste...@suse.cz wrote:
On Fri, Dec 19, 2014 at 02:23:12PM +0800, Qu Wenruo wrote:
In fact, it's not a regression.
The 013 testcase is a special case that uses a script to corrupt the
image and then do the btrfsck test.
There is a patch before the
Hi guys,
The latest integration fails 'make test' with the following output:
[TEST]013-leaf-corruption-no-extent-data.tar.xz
btrfs check should have detected corruption
Makefile:144: recipe for target 'test' failed
make: *** [test] Error 1
rm btrfs-corrupt-block.o
I've only built the
On 18 December 2014 18:35:16 GMT+00:00, WorMzy Tykashi
wormzy.tyka...@gmail.com wrote:
Hi guys,
The latest integration fails 'make test' with the following output:
[TEST]013-leaf-corruption-no-extent-data.tar.xz
btrfs check should have detected corruption
Makefile:144: recipe
On 11 December 2014 at 12:37, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
David,
I was wondering if you could please send out announcements for btrfs-progs
when you tag a release or -rc? There doesn't seem to be a good mechanism
to track releases and IMHO the more people are
Hi guys,
I found a bit of a weird corner-case today. [1] It seems that, due to
the use of a 64-byte constant (ARGV0_BUF_SIZE) in utils.c, some tests
fail with a buffer overflow detected error if the progs are built in
a location with a sufficiently long path.
For example: clone the btrfs-progs
branches. Are these going to be discontinued now that you
are maintaining and tagging the official btrfs-progs releases, or will
they stick around, serving a similar purpose as before?
Cheers,
WorMzy Tykashi
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
On 22 July 2014 15:15, David Sterba dste...@suse.cz wrote:
The tags were meant to mark the points in time where different groups of
patches were added to the to-be-v3.15, but then I noticed that one of
the patches had my note in the subject and Qu sent an updated version
anyway. So I had
Hi David,
The v3.15-rc{2,3,4} tags seem to have disappeared from the unstable
repo in the last day or so. Please could you re-push the tags, or were
they removed for a reason?
Cheers,
WorMzy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
On 2 July 2014 10:34, David Sterba dste...@suse.cz wrote:
Oh sorry, fixed branch pushed. I've added the utils.h inlucde into
cmds-property.c as well, fixes implicit declaration of function
warnings.
Great stuff, thanks.
WorMzy
--
To unsubscribe from this list: send the line unsubscribe
On 2 July 2014 00:11, David Sterba dste...@suse.cz wrote:
On Mon, Jun 30, 2014 at 11:54:11AM +0800, Gui Hecheng wrote:
To let the independent tools(e.g. btrfs-image, btrfs-convert, etc.)
share the convenience of check_argc_* functions, just move it into
utils.c.
Also add a new function
On 19 June 2014 00:05, David Sterba dste...@suse.cz wrote:
On Wed, Jun 18, 2014 at 09:59:50PM +0100, WorMzy Tykashi wrote:
I think you forgot to apply the patch that adds
Documentation/btrfs-mount.5.txt before you tagged
integration-20140618, man5 (and consequently Documentation) can't
On 18 June 2014 16:29, David Sterba dste...@suse.cz wrote:
On Thu, Jun 12, 2014 at 09:39:14AM -0500, Eric Sandeen wrote:
So what if the mount options are generated from btrfs-mount.txt but
installed under btrfs.5.gz name? If there are more section 5 manpages we
can make it more generic but
On 6 June 2014 16:41, Filipe David Manana fdman...@gmail.com wrote:
On Fri, Jun 6, 2014 at 3:40 PM, Roman Mamedov r...@romanrm.net wrote:
Hello,
Not sure if this has been reported somewhere closer to Btrfs development, and
not just in Debian... Anyways, just now I (also) hit this bug when
On 12 May 2014 15:09, David Sterba dste...@suse.cz wrote:
Thanks, it was reported fixed a few days ago, though it's not in the
integration branch, lag is on my side.
https://patchwork.kernel.org/patch/4115501/
Hi David,
I noticed this in another thread:
On 3 June 2014 10:14, David Sterba
Hi,
While trying to view the btrfs-check manpage today (using
integration-20140429), I noticed that the current symlink overwrites
the actual btrfs-check manpage, making an unusable, cyclic link:
$ man btrfs-check
man: can't resolve /usr/share/man/man8/btrfs-check.8.gz: Too many
levels
. Distros
typically put packages like this through their own testing period
anyway, so a prolonged testing period shouldn't be required upstream.
Thanks for your continued hard work,
WorMzy Tykashi
(sorry if you receive this twice gmail went wrong)
--
To unsubscribe from this list: send the line
On 20 March 2014 23:55, Chris Mason c...@fb.com wrote:
On 03/20/2014 07:36 PM, WorMzy Tykashi wrote:
On 25 November 2013 21:45, Chris Mason chris.ma...@fusionio.com wrote:
Hi everyone,
I've tagged the current btrfs-progs repo as v3.12. The new idea is that
instead of making the poor
On 27 February 2014 12:43, Filipe David Manana fdman...@gmail.com wrote:
On Wed, Feb 26, 2014 at 11:26 PM, WorMzy Tykashi
wormzy.tyka...@gmail.com wrote:
Hi,
Hi
Hi again,
Sorry for the delay in replying, I've not had the time to gather my
thoughts and write a coherent reply.
Ever since
On 29 January 2014 21:06, Filipe David Borba Manana fdman...@gmail.com wrote:
After the commit titled Btrfs: fix btrfs boot when compiled as built-in,
LIBCRC32C requirement was removed from btrfs' Kconfig. This made it not
possible to build a kernel with btrfs enabled (either as module or
On 16 February 2014 20:07, GEO 1g2e...@gmail.com wrote:
Hi,
I have been experimenting with btrfs send/receive for incremental backups, but
could not figure out how to exclude certain directories from
subvolumes/snapshots. For example, I want to backup my data in home, but I am
not interested
On 7 February 2014 17:54, David Sterba dste...@suse.cz wrote:
On Fri, Feb 07, 2014 at 12:38:22AM +, WorMzy Tykashi wrote:
Building the latest integration snapshot, I get the following failure:
...
[CC] cmds-filesystem.o
cmds-filesystem.c: In function 'cmd_show':
cmds
Building the latest integration snapshot, I get the following failure:
...
[CC] cmds-filesystem.o
cmds-filesystem.c: In function 'cmd_show':
cmds-filesystem.c:740:12: error: invalid storage class for function 'cmd_sync'
static int cmd_sync(int argc, char **argv)
^
,
WorMzy Tykashi
[1] http://repo.or.cz/r/btrfs-progs-unstable/devel.git
[2] https://github.com/kdave/btrfs-progs
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 11 December 2013 16:37, David Sterba dste...@suse.cz wrote:
Sorry, I haven't pushed the tags, fixed now. The repos are mostly
identical to increase availability.
david
Cheers for that.
WorMzy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
27 matches
Mail list logo
