Hi,
i always encounter btrfs deadlocks / hung tasks, when i have a lot of
cached mem and i'm doing heavy rsync --inplace operations in my system
from btrfs zlib compressed disk A to btrfs zlib compressed disk B.
The last output i see in this case is kswapd0 running for a long time at
100% cpu. Th
On Thu, Sep 22, 2016 at 10:13:08AM +0800, Wang Xiaoguang wrote:
> In btrfs, there is a bug about btrfs' truncate codes, it'll leak
> some fs space as the truncate operation proceeds. If this truncate
> operation is very large, later metadata request in this truncate
> operation may fail for enospc
On 09/21/2016 10:26 PM, David Sterba wrote:
On Sat, Sep 10, 2016 at 07:03:38AM +0800, Anand Jain wrote:
static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
{
struct btrfs_device *device, *tmp;
+ LIST_HEAD(pending_put);
+ INIT_LIST_HEAD(&pending_put);
L
btrfs_show_devname() is using the device_list_mutex, sometimes
a call to blkdev_put() leads vfs calling into this func. So
call blkdev_put() outside of device_list_mutex, as of now.
[ 983.284212] ==
[ 983.290401] [ INFO: possible circular locki
At 09/22/2016 11:07 AM, Christoph Anton Mitterer wrote:
On Thu, 2016-09-22 at 10:08 +0800, Qu Wenruo wrote:
And I don't see the necessary to csum the parity.
Why csum a csum again?
I'd say simply for the following reason:
Imagine the smallest RAID5: 2x data D1 D2, 1x parity P
If D2 is lost i
On Wed, Sep 21, 2016 at 9:00 PM, Qu Wenruo wrote:
>> Both copies are not scrubbed? Oh hell...
>
>
> I was replying to the "--check-data-csum" of btrfsck.
>
> I mean, for --check-data-csum, it doesn't read the backup if the first data
> can be read out without error.
>
> And if the first data is w
On Thu, 2016-09-22 at 10:08 +0800, Qu Wenruo wrote:
> And I don't see the necessary to csum the parity.
> Why csum a csum again?
I'd say simply for the following reason:
Imagine the smallest RAID5: 2x data D1 D2, 1x parity P
If D2 is lost it could be recalculated via D1 and P.
What if only (all)
At 09/22/2016 10:44 AM, Chris Murphy wrote:
On Wed, Sep 21, 2016 at 8:08 PM, Qu Wenruo wrote:
At 09/21/2016 11:13 PM, Chris Murphy wrote:
I understand some things should go in fsck for comparison. But in this
case I don't see how it can help. Parity is not checksummed. The only
way to kn
On Wed, Sep 21, 2016 at 8:08 PM, Qu Wenruo wrote:
>
>
> At 09/21/2016 11:13 PM, Chris Murphy wrote:
>> I understand some things should go in fsck for comparison. But in this
>> case I don't see how it can help. Parity is not checksummed. The only
>> way to know if it's wrong is to read all of the
In btrfs, there is a bug about btrfs' truncate codes, it'll leak
some fs space as the truncate operation proceeds. If this truncate
operation is very large, later metadata request in this truncate
operation may fail for enospc error. I also have sent a kernel
patch fot btrfs to fix this issue.
Sig
At 09/21/2016 11:13 PM, Chris Murphy wrote:
On Wed, Sep 21, 2016 at 3:15 AM, Qu Wenruo wrote:
At 09/21/2016 03:35 PM, Tomasz Torcz wrote:
On Wed, Sep 21, 2016 at 03:28:25PM +0800, Qu Wenruo wrote:
Hi,
For this well-known bug, is there any one fixing it?
It can't be more frustrating fi
On Wed, Sep 21, 2016 at 09:09:32AM -0400, Chris Mason wrote:
>
>
> On 09/21/2016 04:04 AM, David Sterba wrote:
> > On Tue, Sep 20, 2016 at 10:57:41AM -0700, Liu Bo wrote:
> > > On Tue, Sep 20, 2016 at 03:16:36PM +0200, David Sterba wrote:
> > > > On Wed, Sep 14, 2016 at 05:22:57PM -0700, Liu Bo w
On Wed, Sep 21, 2016 at 04:00:05PM +0200, David Sterba wrote:
> On Tue, Sep 06, 2016 at 12:22:01PM -0700, Liu Bo wrote:
> > On Mon, Sep 05, 2016 at 05:20:53PM +0200, David Sterba wrote:
> > > On Fri, Sep 02, 2016 at 06:08:35PM -0700, Liu Bo wrote:
> > > > On Fri, Sep 02, 2016 at 03:25:43PM -0400, J
Hey, guys,
On Wed, Sep 21, 2016 at 08:12:51AM -0400, Austin S. Hemmelgarn wrote:
> On 2016-09-21 06:25, Holger Hoffstätte wrote:
> > On 09/21/16 11:24, David Sterba wrote:
> > > Hi,
> > >
> > > as you might have noticed, the [1] wiki Status page lists the
> > > free-space-tree as 'Unstable', refe
2016-09-21 3:00 GMT+02:00 Chris Murphy :
> On Tue, Sep 20, 2016 at 5:16 PM, Mirak M wrote:
>> Hello,
>>
>> I have a failure when mounting btrfs.
>>
>>> mount -oro,recovery /dev/sda2 sda2_btrfs
>>> mount: /dev/sda2: can't read superblock
>
> What do you get for 'btrfs super-recover -v ' and 'btrfs
On Wed, Sep 21, 2016 at 04:50:12PM +0200, David Sterba wrote:
> On Thu, Aug 18, 2016 at 01:33:27PM -0700, Omar Sandoval wrote:
> > > Omar, looks like we need to make the patched kernel refuse to mount free
> > > space trees without a new incompat bit set. That way there won't be any
> > > surprise
We can hit unused variable warnings when btrfs_debug and friends are
just aliases for no_printk. This is due to the fs_info not getting
consumed by the function call, which can happen if convenenience
variables are used. This patch adds a new btrfs_no_printk static inline
that consumes the conven
On 9/21/16 11:47 AM, Jeff Mahoney wrote:
> On 9/21/16 11:43 AM, David Sterba wrote:
>> Some functions introduced a local fs_info pointer for the message
>> helpers. If btrfs_debug results to an empty macro, the fs_info pointer
>> is reported to be unused. Splitting the variable declaration and sett
On 9/21/16 11:43 AM, David Sterba wrote:
> Some functions introduced a local fs_info pointer for the message
> helpers. If btrfs_debug results to an empty macro, the fs_info pointer
> is reported to be unused. Splitting the variable declaration and setting
> will silence the warning, without any fu
Some functions introduced a local fs_info pointer for the message
helpers. If btrfs_debug results to an empty macro, the fs_info pointer
is reported to be unused. Splitting the variable declaration and setting
will silence the warning, without any functional change.
Signed-off-by: David Sterba
--
On Wed, Sep 21, 2016 at 9:24 AM, Jeffrey Michels wrote:
> Hello,
>
> I've booted into the latest nightly build of Fedora and run btrfs rescue
> super-recover -v and also btrfs check.
>
> Super-recover reports that "All supers are valid, no need to recover." Btrfs
> check displays the same error
On Tue, Sep 20, 2016 at 10:04:58AM -0400, je...@suse.com wrote:
> From: Jeff Mahoney
>
> This is a patchset I've been working on to clean up message printing,
> make it adhere to kernel style, and be more consistent.
>
> The end result is that we:
> * use dynamic debugging for debugging messages
On Tue, Sep 20, 2016 at 10:05:02AM -0400, je...@suse.com wrote:
> static struct btrfs_block_group_cache *
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 6fdc701..c9bb727 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2186,6 +2187,7 @@ void btrfs_free_io_
Hello,
I've booted into the latest nightly build of Fedora and run btrfs rescue
super-recover -v and also btrfs check.
Super-recover reports that "All supers are valid, no need to recover." Btrfs
check displays the same errors as before:
Parent trasid verified failed on wanted found
On Wed, Sep 21, 2016 at 3:15 AM, Qu Wenruo wrote:
>
>
> At 09/21/2016 03:35 PM, Tomasz Torcz wrote:
>>
>> On Wed, Sep 21, 2016 at 03:28:25PM +0800, Qu Wenruo wrote:
>>>
>>> Hi,
>>>
>>> For this well-known bug, is there any one fixing it?
>>>
>>> It can't be more frustrating finding some one has al
On Wed, Sep 21, 2016 at 1:28 AM, Qu Wenruo wrote:
> Hi,
>
> For this well-known bug, is there any one fixing it?
>
> It can't be more frustrating finding some one has already worked on it after
> spending days digging.
>
> BTW, since kernel scrub is somewhat scrap for raid5/6, I'd like to implemen
On Thu, Aug 18, 2016 at 01:33:27PM -0700, Omar Sandoval wrote:
> > Omar, looks like we need to make the patched kernel refuse to mount free
> > space trees without a new incompat bit set. That way there won't be any
> > surprises for the people that have managed to get a free space tree saved.
> >
On Sat, Sep 10, 2016 at 07:03:38AM +0800, Anand Jain wrote:
> static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
> {
> struct btrfs_device *device, *tmp;
> + LIST_HEAD(pending_put);
> + INIT_LIST_HEAD(&pending_put);
LIST_HEAD declares and initializes the list to
On Tue, Sep 20, 2016 at 08:50:21AM -0400, je...@suse.com wrote:
> From: Jeff Mahoney
>
> btrfs_rm_device frees the block device but then re-opens it using
> the saved device name. A race exists between the close and the
> re-open that allows the block size to be changed. The result
> is getting
On Tue, Sep 06, 2016 at 12:22:01PM -0700, Liu Bo wrote:
> On Mon, Sep 05, 2016 at 05:20:53PM +0200, David Sterba wrote:
> > On Fri, Sep 02, 2016 at 06:08:35PM -0700, Liu Bo wrote:
> > > On Fri, Sep 02, 2016 at 03:25:43PM -0400, Josef Bacik wrote:
> > > > We don't track the reloc roots in any sort o
So there's a matrix of possible configurations. If you're doing a
reflink between subvolumes and you're doing a subvolume granular
encryption and you don't have keys to the source subvolume, the reflink
shouldn't be allowed.
Right, this is working.
If you do have keys, any new writes are
On Tue, Sep 13, 2016 at 04:35:52AM +0900, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.
On Wed, Sep 14, 2016 at 05:23:24PM -0700, Liu Bo wrote:
> We need to check items in a node to make sure that we're reading
> a valid one, otherwise we could get various crashes while processing
> delayed_refs.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
--
To unsubscribe from this list:
On 09/21/2016 04:04 AM, David Sterba wrote:
On Tue, Sep 20, 2016 at 10:57:41AM -0700, Liu Bo wrote:
On Tue, Sep 20, 2016 at 03:16:36PM +0200, David Sterba wrote:
On Wed, Sep 14, 2016 at 05:22:57PM -0700, Liu Bo wrote:
During updating btree, we could push items between sibling
nodes/leaves, f
On Wed, Sep 21, 2016 at 11:14:35AM +, Paul Jones wrote:
> > -Original Message-
> > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> > ow...@vger.kernel.org] On Behalf Of Zygo Blaxell
> > Sent: Wednesday, 21 September 2016 2:56 PM
> > To: linux-btrfs@vger.kernel.org
> > Sub
From: Jeff Mahoney
There was a bug where the btrfs snapshot/subvol creation ioctls
would accept a regular file and then Oops when it tried to use
the file inode operations to do a lookup.
This also adds an ioctl-helper that can be easily extended to provide
direct ioctl access for any file syste
From: Jeff Mahoney
If the subvol/snapshot create/destroy ioctls are passed a regular file
with execute permissions set, we'll eventually Oops while trying to do
inode->i_op->lookup via lookup_one_len.
This patch ensures that the file descriptor refers to a directory.
Fixes: cb8e70901d (Btrfs: F
On 2016-09-21 06:25, Holger Hoffstätte wrote:
On 09/21/16 11:24, David Sterba wrote:
Hi,
as you might have noticed, the [1] wiki Status page lists the
free-space-tree as 'Unstable', referencing a problem with the bitmap
endianity. This will affect only bigendian systems.
There's one more probl
Hi,
btrfs-progs 4.7.3 have been released, bugfix release. There are some minor
fixes, notably the free-space-tree compat status was wrong, see [1] for more.
Some fuzzer bugs have been fixed, but there are still several open.
Changes:
* fixed free space tree compat status
* check: low-mem mode
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Zygo Blaxell
> Sent: Wednesday, 21 September 2016 2:56 PM
> To: linux-btrfs@vger.kernel.org
> Subject: btrfs rare silent data corruption with kernel data leak
>
> Summa
On 2016-09-20 15:55, Chris Murphy wrote:
On Tue, Sep 20, 2016 at 1:43 PM, Austin S. Hemmelgarn
wrote:
First off, as Chris said, if you can read the data and don't already have a
backup, that should be your first priority. This really is an edge case
that's not well tested, and the kernel tec
On 09/21/16 11:24, David Sterba wrote:
> Hi,
>
> as you might have noticed, the [1] wiki Status page lists the
> free-space-tree as 'Unstable', referencing a problem with the bitmap
> endianity. This will affect only bigendian systems.
>
> There's one more problem that I overlooked but was pointe
Hi,
Just bumped into this, let me know if you need more info:
[160997.651655] [ cut here ]
[160997.656497] kernel BUG at
/build/linux-a2WvEb/linux-4.4.0/fs/btrfs/inode.c:3258!
[160997.664083] invalid opcode: [#1] SMP
[160997.668604] Modules linked in: ufs msdos xfs xt_
Hi,
as you might have noticed, the [1] wiki Status page lists the
free-space-tree as 'Unstable', referencing a problem with the bitmap
endianity. This will affect only bigendian systems.
There's one more problem that I overlooked but was pointed to by Omar
recently. The initial FST support in bt
At 09/21/2016 03:35 PM, Tomasz Torcz wrote:
On Wed, Sep 21, 2016 at 03:28:25PM +0800, Qu Wenruo wrote:
Hi,
For this well-known bug, is there any one fixing it?
It can't be more frustrating finding some one has already worked on it after
spending days digging.
BTW, since kernel scrub is some
On Wed, Sep 21, 2016 at 03:28:25PM +0800, Qu Wenruo wrote:
> Hi,
>
> For this well-known bug, is there any one fixing it?
>
> It can't be more frustrating finding some one has already worked on it after
> spending days digging.
>
> BTW, since kernel scrub is somewhat scrap for raid5/6, I'd like
On Tue, Sep 20, 2016 at 10:59:59AM -0700, Liu Bo wrote:
> On Tue, Sep 20, 2016 at 10:03:43AM +0200, David Sterba wrote:
> > On Mon, Sep 19, 2016 at 04:11:44PM -0700, Liu Bo wrote:
> > > > > That's EIO. Sometimes the EIO is big enough we have to abort, but
> > > > > really the abort is just adding
On Tue, Sep 20, 2016 at 10:57:41AM -0700, Liu Bo wrote:
> On Tue, Sep 20, 2016 at 03:16:36PM +0200, David Sterba wrote:
> > On Wed, Sep 14, 2016 at 05:22:57PM -0700, Liu Bo wrote:
> > > During updating btree, we could push items between sibling
> > > nodes/leaves, for leaves data sections starts re
Hi,
For this well-known bug, is there any one fixing it?
It can't be more frustrating finding some one has already worked on it
after spending days digging.
BTW, since kernel scrub is somewhat scrap for raid5/6, I'd like to
implement btrfsck scrub support, at least we can use btrfsck to fix
In flush_space()->shrink_delalloc(), if can_overcommit() returns true,
though no bytes added to space_info, we still may satisfy some requests.
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/extent-tree.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/fs
Indeed as long as we have delalloc bytes and if we fail to reclaim
requested metadata space, we should write these delalloc bytes and
have one more try, this can fix some false enospc errors in some
extreme cases.
Signed-off-by: Wang Xiaoguang
---
fs/btrfs/extent-tree.c | 9 +
1 file cha
51 matches
Mail list logo
