I am very sorry that my commit caused the problem.
In fact some users have already find the problem and I sent the fix some
time ago.
The patch is https://patchwork.kernel.org/patch/4842201/
Hopes this helps.
Thanks,
Qu
Original Message
Subject: Re: [bug] subvol doesn't
On Thu, 2014-09-18 at 13:59 +0800, Anand Jain wrote:
Hi Gui,
Thanks for the attempt to fix this. more below..
On 09/18/2014 11:31 AM, Gui Hecheng wrote:
*Note*: this handles the problem under umounted state,
the problem under mounted state is already fixed by Anand.
Steps
Hi Eric,
This:
# truncate --size=8g
# dd if=/dev/zero of=file conv=notrunc bs=4 seek=16384 count=1
# valgrind ./btrfs rescue super-recover file -v
yields:
==4604== Memcheck, a memory error detector
==4604== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4604==
On Thu, Sep 18, 2014 at 01:36:47PM +0800, Qu Wenruo wrote:
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping()
to insert best fitted extent map
From: Liu Bo bo.li@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年09月18日 12:21
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Liu Bo bo.li@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年09月18日 15:33
On Thu, Sep 18, 2014 at 01:36:47PM +0800, Qu Wenruo wrote:
Am Donnerstag, 18. September 2014, 11:39:21 schrieb Gui Hecheng:
On Mon, 2014-09-01 at 15:25 +, Zooko Wilcox-OHearn wrote:
I'm more than happy to try out patches and even focus my own brain on
diagnosing it, if I can. I'm hoping to regain access to some of my
files on my btrfs
On Thu, Sep 18, 2014 at 03:58:26PM +0800, Qu Wenruo wrote:
[...]
original: (start = existing-start start extent_map_end(existing))
this patch: (start extent_map_end(existing) start + len
existing-start)
(start + len existing-start) doesn't equal to start = existing-start,
here
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Liu Bo bo.li@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年09月18日 16:20
On Thu, Sep 18, 2014 at 03:58:26PM +0800, Qu Wenruo wrote:
Hello Gui,
Am Donnerstag, 18. September 2014, 11:34:43 schrieb Gui Hecheng:
When runing restore under lzo compression, bad compress length
problems are encountered.
It is because there is a page align problem with the @decompress_lzo,
as follows:
|--| ||-|
From: Naohiro Aota na...@elisp.net
We can enable both compress option and nodatasum option at the same time
with the following command.
===
$ sudo mount -o remount,compress,nodatasum /
$ mount | grep btrfs
/dev/vda2 on / type btrfs
(rw,relatime,seclabel,nodatasum,compress=zlib,space_cache)
===
From: Naohiro Aota na...@elisp.net
If we set nodatacow mount option after compress-force option,
we don't get compression disabling message.
===
$ sudo mount -o remount,compress-force,nodatacow /; dmesg|tail -n 3
[ 3845.719047] BTRFS info (device vda2): force zlib compression
[ 3845.719052]
From: Naohiro Aota na...@elisp.net
Documentation/filesystems/btrfs.txt states the following:
===
...
Nodatacow implies nodatasum, and disables all compression.
...
===
However the current message only mentions nodatacow. It's better to
also mention nodatasum.
Signed-off-by: Naohiro Aota
From: Naohiro Aota na...@elisp.net
Remount operation always tells you it enabled space cache.
I consider it's a bit verbose and is better not to show
this message on remounting.
Signed-off-by: Naohiro Aota na...@elisp.net
Signed-off-by: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
---
From: Naohiro Aota na...@elisp.net
There are mutual exclusive mount options corresponding to
compression options. If we set these options at once, we get
improper messages and states, and a verbose message.
* Improper states
- We can't disable compress forcing with compress={zlib,lzo}
The following commit enhanced the merge_extent_mapping() to reduce
fragment in extent map tree, but it can't handle case which existing
lies before map_start:
51f39 btrfs: Use right extent length when inserting overlap extent map.
[BUG]
When existing extent map's start is before map_start,
the
On Thu, Sep 18, 2014 at 04:24:48PM +0800, Qu Wenruo wrote:
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping()
to insert best fitted extent map
From: Liu Bo bo.li@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年09月18日 16:20
super-recover collects btrfs devices infomation using existed
functions scan_one_devices().
Problem is fs_devices is freed twice in close_ctree() and
free_recover_superblock() for super correction path.
Fix this problem by checking whether fs_devices memory
have been freed before we free it.
On Thu, 2014-09-18 at 10:25 +0200, Marc Dietrich wrote:
Hello Gui,
Am Donnerstag, 18. September 2014, 11:34:43 schrieb Gui Hecheng:
When runing restore under lzo compression, bad compress length
problems are encountered.
It is because there is a page align problem with the
On Thu, 2014-09-18 at 05:01 -0400, Wang Shilong wrote:
super-recover collects btrfs devices infomation using existed
functions scan_one_devices().
Problem is fs_devices is freed twice in close_ctree() and
free_recover_superblock() for super correction path.
Fix this problem by checking
Am Donnerstag, 18. September 2014, 17:10:54 schrieb Gui Hecheng:
On Thu, 2014-09-18 at 10:25 +0200, Marc Dietrich wrote:
Hello Gui,
Am Donnerstag, 18. September 2014, 11:34:43 schrieb Gui Hecheng:
When runing restore under lzo compression, bad compress length
problems are
The RCU-friendy string API used internally by BTRFS is generic enough for
common use. This doesn't add any new functionality, but instead just moves the
code and documents the existing API.
Signed-off-by: Omar Sandoval osan...@osandov.com
---
This patch applies to 3.17-rc5.
On Thu, 2014-09-18 at 11:25 +0200, Marc Dietrich wrote:
Am Donnerstag, 18. September 2014, 17:10:54 schrieb Gui Hecheng:
On Thu, 2014-09-18 at 10:25 +0200, Marc Dietrich wrote:
Hello Gui,
Am Donnerstag, 18. September 2014, 11:34:43 schrieb Gui Hecheng:
When runing restore under
Thank you! I will try to restore using this patch.
What branch of what btrfs tools git repo should I apply the patch to?
Regards,
Zooko
--
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
On Wed, Sep 17, 2014 at 4:53 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
The following commit enhanced the merge_extent_mapping() to reduce
fragment in extent map tree, but it can't handle case which existing
lies before map_start:
51f39 btrfs: Use right extent length when inserting overlap
On 09/17/2014 08:49 PM, Chris Murphy wrote:
This isn't what I expect as a candidate for btrfs-zero-log, I don't know what
the last message means. You could run a
btrfs check btrfsdev
and then ask about both the failure to read block groups -5 and also the
btrfs check (without --repair)
Hello,
I get corruption with btrfs in a loop device with linux-3.16.3
(https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/
for-linus applied).
I never had a problem with this setup until 3.16.
This happened just after unpacking a few thousand small files and
reading them back with
- Original Message -
From: Omar Sandoval osan...@osandov.com
To: Chris Mason c...@fb.com, Josef Bacik jba...@fb.com,
linux-btrfs@vger.kernel.org, Paul E. McKenney
paul...@linux.vnet.ibm.com, Josh Triplett j...@joshtriplett.org,
Steven Rostedt rost...@goodmis.org,
Mathieu Desnoyers
Hi everyone,
I've added a few more patches to the kernel integration branch, and
rebased onto rc5. This should be my last rebase before sending into
linux-next, please take a look.
It's still missing three patches from Josef, which we're updating. I
can put more patches on top, but I'd prefer
Johannes and Sam, could you please confirm this patch fixes your mount
regression for now? Anand, please make sure I kept the generation check
properly.
This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.
This commit is triggering failures to mount by subvolume id in some
One problem that has plagued us is that a user will use up all of his space with
data, remove a bunch of that data, and then try to create a bunch of small files
and run out of space. This happens because all the chunks were allocated for
data since the metadata requirements were so low. But now
Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
during log replay. This is because we use fs_info-fs_root as our root for
shrinking and such. Technically we can use whatever root we want, but let's
just not allow async reclaim while we're doing log replay. Thanks,
While debugging a btrfs send/receive slow problem, I now getting this:
legolas:/mnt/btrfs_pool1# btrfs send -p tmp_ggm_daily_ro.20140917_06:29:58
tmp_ggm_daily_ro.20140918_02:48:24 | ssh gargamel btrfs receive -v
/mnt/btrfs_pool2/backup/debian64/legolas
At subvol
On Thu, Sep 18, 2014 at 08:27:18AM -0700, Marc MERLIN wrote:
While debugging a btrfs send/receive slow problem, I now getting this:
legolas:/mnt/btrfs_pool1# btrfs send -p tmp_ggm_daily_ro.20140917_06:29:58
tmp_ggm_daily_ro.20140918_02:48:24 | ssh gargamel btrfs receive -v
On Thu, Sep 18, 2014 at 04:39:34PM +0100, Hugo Mills wrote:
Now it seems that the UUID is different on all my snapshots created by
btrfs send, so maybe it doesn't match UUID?
Given that, what is btrfs receive using to get a match?
There's a recieved UUID field on each subvolume. I
On 09/17/2014 02:57 PM, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote:
Thanks for all the help.
Well, it's not much help. It seems possible to corrupt a primary superblock
that points to a corrupt tree root, and use btrfs rescure
On 09/17/2014 04:22 PM, Duncan wrote:
Austin S Hemmelgarn posted on Wed, 17 Sep 2014 07:23:46 -0400 as
excerpted:
I've also discovered, when trying to use btrfs restore to copy out the
data to a different system, that 3.14.1 restore apparently chokes on
filesystem that have lzo compression
Hey Fellow Btrfs Developers,
I am wondering how to run the xfs tests for btrfs as I tried to do it based on
a link online
written I believe a few years ago. If someone can help me get set up for
testing the btrfs
code using xfs tests that would be great. In addition afterwards I already
build
On Sep 18, 2014, at 11:12 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 09/17/2014 02:57 PM, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com
wrote:
Thanks for all the help.
Well, it's not much help. It seems possible to corrupt a
Austin S Hemmelgarn posted on Thu, 18 Sep 2014 13:12:03 -0400 as
excerpted:
Secondarily, this almost makes me want to set the ssd option on all
BTRFS filesystems, just to get the rotating superblock updates, because
if it weren't for that behavior, I probably wouldn't have been able to
On 26 August 2014 15:22, Chris Mason c...@fb.com wrote:
Hi everyone,
I've just tagged btrfs-progs v3.16. Like the last few releases, this
one was prepared by Dave Sterba, who has been wrangling btrfs-progs
patches for some time now.
Dave has asked to officially take over the btrfs-progs
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Filipe David Manana fdman...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年09月18日 21:16
On Wed, Sep 17, 2014 at 4:53 AM, Qu Wenruo
Hi,
Xfstests uses several environment variants to setup the test environment.
You can set it manually using export, or write them into local.conf in
xfstests directory.
These environment variants are mandatory:
TEST_DEV: device for normal tests, like all generic tests
TEST_DIR: where TEST_DEV
On 14-09-18 09:08 PM, Qu Wenruo wrote:
Hi,
Xfstests uses several environment variants to setup the test environment.
You can set it manually using export, or write them into local.conf in
xfstests directory.
These environment variants are mandatory:
TEST_DEV: device for normal tests,
On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote:
Thank you! I will try to restore using this patch.
What branch of what btrfs tools git repo should I apply the patch to?
Regards,
Zooko
At least I think the following repo/v3.17.x branch has all
restore-related patches
Original Message
Subject: Re: XFS Tests for Btrfs
From: nick yoc...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年09月19日 09:17
On 14-09-18 09:08 PM, Qu Wenruo wrote:
Hi,
Xfstests uses several environment variants to setup the test
On 14-09-18 09:40 PM, Qu Wenruo wrote:
Original Message
Subject: Re: XFS Tests for Btrfs
From: nick yoc...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年09月19日 09:17
On 14-09-18 09:08 PM, Qu Wenruo wrote:
Hi,
Xfstests uses
Hi Chris,
I'm sorry that the commit 'btrfs: Fix and enhance merge_extent_mapping()
to insert best fitted extent map'
has a V2 patch, so the one in tree is not up-to-data.
Although the v2 change is quite small and it's relevantly dependent, so
it should not be a pain change.
Thanks,
Qu
Original Message
Subject: Re: XFS Tests for Btrfs
From: nick yoc...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年09月19日 09:41
On 14-09-18 09:40 PM, Qu Wenruo wrote:
Original Message
Subject: Re: XFS Tests for Btrfs
From: Naohiro Aota na...@elisp.net
There are many trivial typos in Documentation/*.txt.
All of these use exist status to mean exit status
by mistake. I guess someone first made this mistake
and it has spread by copy-and-paste :-D
Signed-off-by: Naohiro Aota na...@elisp.net
Signed-off-by: Satoru
On 14-09-18 09:46 PM, Qu Wenruo wrote:
Original Message
Subject: Re: XFS Tests for Btrfs
From: nick yoc...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年09月19日 09:41
On 14-09-18 09:40 PM, Qu Wenruo wrote:
Original
Original Message
Subject: [PATCH 2/5] btrfs: correct a message on setting nodatacow
From: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
To: linux-btrfs@vger.kernel.org linux-btrfs@vger.kernel.org
Date: 2014年09月18日 16:28
From: Naohiro Aota na...@elisp.net
If we set nodatacow
Chris
On Fri, 19 Sep 2014 09:45:17 +0800, Qu Wenruo wrote:
Hi Chris,
I'm sorry that the commit 'btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map'
has a V2 patch, so the one in tree is not up-to-data.
Although the v2 change is quite small and it's
52 matches
Mail list logo
