Re: [PATCH] btrfs-progs: doc: Update docs about RAID profiles

Austin S. Hemmelgarn posted on Thu, 01 Dec 2016 15:01:17 -0500 as excerpted: > This adds some more info about chunk profiles in the mkfs manpage, > specifically providing better info about raid1 and raid10 profiles and > the fact that they can't survive more than one device failing. > > This

[PATCH 08/18] btrfs: root->fs_info cleanup, io_ctl_init

From: Jeff Mahoney The io_ctl->root member was only being used to access root->fs_info. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 2 +- fs/btrfs/free-space-cache.c | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff

[PATCH 11/18] btrfs: root->fs_info cleanup, lock/unlock_chunks

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/disk-io.c | 4 +-- fs/btrfs/extent-tree.c | 8 +++--- fs/btrfs/free-space-cache.c | 4 +-- fs/btrfs/volumes.c | 70 ++---

[PATCH 14/18] btrfs: root->fs_info cleanup, access fs_info->delayed_root directly

From: Jeff Mahoney This results in btrfs_assert_delayed_root_empty and btrfs_destroy_delayed_inode taking an fs_info instead of a root. Signed-off-by: Jeff Mahoney --- fs/btrfs/delayed-inode.c | 23 ++- fs/btrfs/delayed-inode.h | 4 ++--

[PATCH 03/18] btrfs: btrfs_init_new_device should use fs_info->dev_root

From: Jeff Mahoney btrfs_init_new_device only uses the root passed in via the ioctl to start the transaction. Nothing else that happens is related to whatever root the user used to initiate the ioctl. We can drop the root requirement and just use fs_info->dev_root instead.

[PATCH 00/18] misc-4.10: root->fs_info patchset

From: Jeff Mahoney Hi all - Here's the latest version of my root->fs_info patchset. It's against Dave's misc-4.10 branch. -Jeff --- Jeff Mahoney (18): btrfs: call functions that overwrite their root parameter with fs_info btrfs: call functions that always use the same

[PATCH 15/18] btrfs: convert extent-tree tracepoints to use fs_info

From: Jeff Mahoney The extent-tree tracepoints all operate on the extent root, regardless of which root is passed in. Let's just use the extent root objectid instead. If it turns out that nobody is depending on the format of this tracepoint, we can drop the root printing

[PATCH 02/18] btrfs: call functions that always use the same root with fs_info instead

From: Jeff Mahoney There are many functions that are always called with the same root argument. Rather than passing the same root every time, we can pass an fs_info pointer instead and have the function get the root pointer itself. Signed-off-by: Jeff Mahoney

[PATCH 05/18] btrfs: struct btrfsic_state->root should be an fs_info

From: Jeff Mahoney The root member is never used except for obtaining an fs_info pointer. Signed-off-by: Jeff Mahoney --- fs/btrfs/check-integrity.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH 18/18] btrfs: split btrfs_wait_marked_extents into normal and tree log functions

From: Jeff Mahoney btrfs_write_and_wait_marked_extents and btrfs_sync_log both call btrfs_wait_marked_extents, which provides a core loop and then handles errors differently based on whether it's it's a log root or not. This means that btrfs_write_and_wait_marked_extents needs

[PATCH 10/18] btrfs: root->fs_info cleanup, btrfs_calc_{trans,trunc}_metadata_size

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 8 fs/btrfs/delayed-inode.c| 4 ++-- fs/btrfs/extent-tree.c | 35 +++ fs/btrfs/file.c | 4 ++--

[PATCH 01/18] btrfs: call functions that overwrite their root parameter with fs_info

From: Jeff Mahoney There are 11 functions that accept a root parameter and immediately overwrite it. We can pass those an fs_info pointer instead. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 4 ++-- fs/btrfs/disk-io.c | 4 ++--

[PATCH 07/18] btrfs: root->fs_info cleanup, use fs_info->dev_root everywhere

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/check-integrity.c | 2 +- fs/btrfs/disk-io.c | 4 +-- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/scrub.c | 86 +++--- fs/btrfs/volumes.c

[PATCH 16/18] btrfs: simplify btrfs_wait_cache_io prototype

From: Jeff Mahoney With the exception of the one case where btrfs_wait_cache_io is called without a block group, it's called with the same arguments. The root argument is only used in the special case, so let's factor out the core and simplify the call in the normal case to

[PATCH 04/18] btrfs: alloc_reserved_file_extent trace point should use extent_root

From: Jeff Mahoney Even though a separate root is passed in, we're still operating on the extent root. Let's use that for the trace point. Signed-off-by: Jeff Mahoney --- fs/btrfs/extent-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH 06/18] btrfs: struct reada_control.root -> reada_control.fs_info

From: Jeff Mahoney The root is never used. We substitute extent_root in for the reada_find_extent call, since it's only ever used to obtain the node size. This call site will be changed to use fs_info in a later patch. Signed-off-by: Jeff Mahoney ---

[PATCH 12/18] btrfs: root->fs_info cleanup, update_block_group{,flags}

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/extent-tree.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index cc9ae54..2e395d4 100644 ---

btrfs lockdep warning: possible recursive locking of >log_mutex

When using btrfs and a kernel with lockdep enabled (4.9-rc7, but this easily could have been there for a while) I got the following lockdep warning: [ 37.796703] = [ 37.796773] [ INFO: possible recursive locking detected ] [ 37.796854] 4.9.0-rc7

[PATCH 2/2] btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges

[BUG] For the following case, btrfs can underflow qgroup reserved space at error path: (Page size 4K, function name without "btrfs_" prefix) Task A | Task B -- Buffered_write [0, 2K)

[PATCH 1/2] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

Introduce a new parameter, struct extent_changeset for btrfs_qgroup_reserved_data() and its callers. Such extent_changeset was used in btrfs_qgroup_reserve_data() to record which range it reserved in current reserve, so it can free it at error path. The reason we need to export it to callers is,

Re: resend: Re: Btrfs: adjust len of writes if following a preallocated extent

On Thu, Nov 24, 2016 at 11:13:37AM +, Filipe Manana wrote: > On Wed, Nov 23, 2016 at 9:22 PM, Liu Bo wrote: > > Hi, > > > > On Wed, Nov 23, 2016 at 06:21:35PM +0100, Stefan Priebe - Profihost AG > > wrote: > >> Hi, > >> > >> sorry last mail was from the wrong box. > >>

Re: [PATCH] Btrfs: fix infinite loop when tree log recovery

Hi Filipe, Thank you for your help. I will make up the incremental send change log as soon as possible. Thanks. robbieko Filipe Manana 於 2016-12-01 19:14 寫到: On Thu, Dec 1, 2016 at 1:42 AM, robbieko wrote: Hi Filipe, Thank you for your review. I have seen your

Re: [PATCH] fstests: btrfs, add missing umount for raid5 tests 124 and 125

Hi, I didn't add umount at end of the test because... _check_btrfs_filesystem() does it, which gets called as this test does not specify _require_scratch_nocheck _check_btrfs_filesystem() { device=$1 # If type is set, we're mounted type=`_fs_type $device`

ITS HIER WIEDER!

-- Guten Tag Ihnen, Sie benötigen finanzielle Unterstützung für Ihr Unternehmen? Oder benötigen Sie einen persönlichen Kredit? Wir bieten ein legitimes Darlehen zu 2% Zinsen pro Jahr. Für die Anwendung kontaktieren Sie uns bitte. Wir sind in Australien und wir bieten Darlehen für

Re: 4.8.8, bcache deadlock and hard lockup

On Wed, 30 Nov 2016, Marc MERLIN wrote: > On Wed, Nov 30, 2016 at 03:57:28PM -0800, Eric Wheeler wrote: > > > I'll start another separate thread with the btrfs folks on how much > > > pressure is put on the system, but on your side it would be good to help > > > ensure that bcache doesn't crash

Re: Convert from RAID 5 to 10

FYI. There is an old saying in embedded circles that I revolve that evolved from Arthur C Clarke "Any sufficiently advanced technology is indistinguishable from magic." Engineering version states "Any sufficiently advanced incompetence is indistinguishable from malice" Also I'll quote you on

[PATCH] Btrfs: fix btrfs_ordered_update_i_size to update disk_i_size properly

btrfs_ordered_update_i_size can be called by truncate and endio, but only endio takes ordered_extent which contains the completed IO. while truncating down a file, if there are some in-flight IOs, btrfs_ordered_update_i_size in endio will set disk_i_size to @orig_offset that is zero. If

[PATCH] Btrfs: fix lockdep warning about log_mutex

While checking INODE_REF/INODE_EXTREF for a corner case, we may acquire a different inode's log_mutex with holding the current inode's log_mutex, and lockdep has complained this with a possilble deadlock warning. Fix this by using mutex_lock_nested() when processing the other inode's log_mutex.

[PATCH] Btrfs: add truncated_len for ordered extent tracepoints

This can help us monitor truncated ordered extents. Signed-off-by: Liu Bo --- include/trace/events/btrfs.h | 4 1 file changed, 4 insertions(+) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index e030d6f..1dc1197 100644 ---

[PATCH] Btrfs: use down_read_nested to make lockdep silent

If @block_group is not @used_bg, it'll try to get @used_bg's lock without droping @block_group 's lock and lockdep has throwed a scary deadlock warning about it. Fix it by using down_read_nested. Signed-off-by: Liu Bo --- fs/btrfs/extent-tree.c | 3 ++- 1 file changed, 2

[PATCH] Btrfs: add 'inode' for extent map tracepoint

'inode' is an important field for btrfs_get_extent, lets trace it. Signed-off-by: Liu Bo --- fs/btrfs/inode.c | 2 +- include/trace/events/btrfs.h | 13 - 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/inode.c

[PATCH v2] Btrfs: fix truncate down when no_holes feature is enabled

For such a file mapping, [0-4k][hole][8k-12k] In NO_HOLES mode, we don't have the [hole] extent any more. Commit c1aa45759e90 ("Btrfs: fix shrinking truncate when the no_holes feature is enabled") fixed disk isize not being updated in NO_HOLES mode when data is not flushed. However, even if

Re: btrfs flooding the I/O subsystem and hanging the machine, with bcache cache turned off

Is there any fundamental reason not to support huge writeback caches? (I mean, besides working around bugs and/or questionably poor design choices which no one wishes to fix.) The obvious drawback is the increased risk of data loss upon hardware failure or kernel panic but why couldn't the user be

Re: [PATCH] btrfs-progs: add dev stats returncode option

On 1 December 2016 at 18:43, Austin S. Hemmelgarn wrote: > Currently, `btrfs device stats` returns non-zero only when there was an > error getting the counter values. This is fine for when it gets run by a > user directly, but is a serious pain when trying to use it in a

[PATCH] btrfs-progs: doc: Update docs about RAID profiles

This adds some more info about chunk profiles in the mkfs manpage, specifically providing better info about raid1 and raid10 profiles and the fact that they can't survive more than one device failing. This should hopefully make it less likely that people hit unexpected behavior when using these

[PATCH] btrfs-progs: add dev stats returncode option

Currently, `btrfs device stats` returns non-zero only when there was an error getting the counter values. This is fine for when it gets run by a user directly, but is a serious pain when trying to use it in a script or for monitoring since you need to parse the (not at all machine friendly)

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 16:48 schrieb Chris Murphy: > On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG > wrote: >> >> Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: >>> On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: On Thu, Dec 1, 2016 at 10:49 AM, Stefan

Re: Convert from RAID 5 to 10

On Wed, Nov 30, 2016 at 1:29 PM, Tomasz Kusmierz wrote: > Please, I beg you add another column to man and wiki stating clearly > how many devices every profile can withstand to loose. I frequently > have to explain how btrfs profiles work and show quotes from this >

[PATCH] btrfs-progs: Initialize ret to suppress compiler warning

From: Goldwyn Rodrigues Signed-off-by: Goldwyn Rodrigues --- cmds-check.c| 2 +- qgroup-verify.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 85eaa63..a9501f5 100644 --- a/cmds-check.c +++

[PATCH] btrfs-progs: Fix extents after finding all errors

From: Goldwyn Rodrigues Simplifying the logic of fixing. Calling fixup_extent_ref() after encountering every error causes more error messages after the extent is fixed. In case of multiple errors, this is confusing because the error message is displayed after the fix message

[PATCH] btrfs-progs: find_free_dev_extent() closer to kernel code

From: Goldwyn Rodrigues This solves an ENOSPC issue with nearly full filesystems. The only things missing from the function is contains_pending_extent() which should not be required in this case. Signed-off-by: Goldwyn Rodrigues --- volumes.c | 191

Re: btrfs flooding the I/O subsystem and hanging the machine, with bcache cache turned off

On Wed 30-11-16 10:16:53, Marc MERLIN wrote: > +folks from linux-mm thread for your suggestion > > On Wed, Nov 30, 2016 at 01:00:45PM -0500, Austin S. Hemmelgarn wrote: > > > swraid5 < bcache < dmcrypt < btrfs > > > > > > Copying with btrfs send/receive causes massive hangs on the system. > > >

Re: Metadata balance fails ENOSPC

On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG wrote: > > Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: >> On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: >>> On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG >>>

Re: btrfs_destroy_inode warn (outstanding extents)

On Wed, Nov 23, 2016 at 02:58:45PM -0500, Dave Jones wrote: > On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote: > > > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4 > > trace from just before this happened. Does this shed any light ? > > > >

Re: [PATCH V2] btrfs-progs: Use helper function to access btrfs_super_block->sys_chunk_array_size

On Thu, Dec 01, 2016 at 07:21:14PM +0530, Chandan Rajendra wrote: > btrfs_super_block->sys_chunk_array_size is stored as le32 data on > disk. However insert_temp_chunk_item() writes sys_chunk_array_size in > host cpu order. This commit fixes this by using super block access > helper functions to

LSF/MM 2017: Call for Proposals

The annual Linux Storage, Filesystem and Memory Management (LSF/MM) Summit for 2017 will be held on March 20th and 21st at the Hyatt Cambridge, Cambridge, MA. LSF/MM is an invitation-only technical workshop to map out improvements to the Linux storage, filesystem and memory management subsystems

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: > On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: >> On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG >> wrote: >> ... >>> >>> Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7 >>> which

Re: Metadata balance fails ENOSPC

On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: > On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG > wrote: > ... >> >> Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7 >> which does the same. >> >> # btrfs filesystem show /ssddisk/

[PATCH V2] btrfs-progs: Use helper function to access btrfs_super_block->sys_chunk_array_size

btrfs_super_block->sys_chunk_array_size is stored as le32 data on disk. However insert_temp_chunk_item() writes sys_chunk_array_size in host cpu order. This commit fixes this by using super block access helper functions to read and write btrfs_super_block->sys_chunk_array_size field.

Re: Metadata balance fails ENOSPC

I've frequently seen free space cache corruption lead to phantom ENOSPC. You could try clearing the space cache, and/or mounting with nospache_cache. On Thu, Dec 1, 2016 at 6:55 AM, Stefan Priebe - Profihost AG wrote: > > Am 01.12.2016 um 09:12 schrieb Andrei Borzenkov: >>

Re: 4.8.8, bcache deadlock and hard lockup

On 2016-11-30 19:48, Chris Murphy wrote: On Wed, Nov 30, 2016 at 4:57 PM, Eric Wheeler wrote: On Wed, 30 Nov 2016, Marc MERLIN wrote: +btrfs mailing list, see below why On Tue, Nov 29, 2016 at 12:59:44PM -0800, Eric Wheeler wrote: On Mon, 27 Nov 2016, Coly Li

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 09:12 schrieb Andrei Borzenkov: > On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG > wrote: > ... >> >> Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7 >> which does the same. >> >> # btrfs filesystem show /ssddisk/

Re: Convert from RAID 5 to 10

On giovedì 1 dicembre 2016 10:37:13 CET, Wilson Meier wrote: The only thing i have asked for is to document the *known* problems/flaws/limitations of all raid profiles and link to them from the stability matrix. +1 Do someone mind if I ask for an account and I start copy-pasting any relevant

Re: [PATCH] Btrfs: fix infinite loop when tree log recovery

On Thu, Dec 1, 2016 at 1:42 AM, robbieko wrote: > Hi Filipe, > > Thank you for your review. > I have seen your modified change log with below > Btrfs: fix tree search logic when replaying directory entry deletes > Btrfs: fix deadlock caused by fsync when logging

Re: Convert from RAID 5 to 10

Am 30/11/16 um 17:48 schrieb Austin S. Hemmelgarn: > On 2016-11-30 10:49, Wilson Meier wrote: >> Am 30/11/16 um 15:37 schrieb Austin S. Hemmelgarn: >> >> Transferring this to car analogy, just to make it a bit more funny: >> The airbag (raid level whatever) itself is ok but the micro controller >>

Re: Metadata balance fails ENOSPC

On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG wrote: ... > > Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7 > which does the same. > > >>> # btrfs filesystem show /ssddisk/ >>> Label: none uuid: a69d2e90-c2ca-4589-9876-234446868adc

Re: Metadata balance fails ENOSPC

Chris Murphy posted on Wed, 30 Nov 2016 16:02:29 -0700 as excerpted: > On Wed, Nov 30, 2016 at 2:03 PM, Stefan Priebe - Profihost AG > wrote: >> Hello, >> >> # btrfs balance start -v -dusage=0 -musage=1 /ssddisk/ >> Dumping filters: flags 0x7, state 0x0, force is off >>