Re: [PATCH v2] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Fri, Apr 27, 2018 at 2:06 AM, David Sterba wrote: > On Thu, Apr 26, 2018 at 09:27:43AM +0800, Liu Bo wrote: >> path->keep_lock may force to lock tree root and higher nodes, and make >> lock contention worse, thus it needs to be avoided as much as >> possible. >> >> In

Re: [PATCH] btrfs: Add test that checks rmdir(2) can delete a subvolume

On Thu, Apr 19, 2018 at 04:23:35PM +0900, Misono Tomohiro wrote: > Add btrfs test that checks "rmdir" or "rm -r" command can delete a > subvolume like an ordinary drectory. > > This behavior has been restricted long time but becomes allowed by > following patch in the kernel: > btrfs: Allow

Re: [PATCH v2] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Fri, Apr 27, 2018 at 2:06 AM, David Sterba wrote: > On Thu, Apr 26, 2018 at 09:27:43AM +0800, Liu Bo wrote: >> path->keep_lock may force to lock tree root and higher nodes, and make >> lock contention worse, thus it needs to be avoided as much as >> possible. >> >> In

Re: [PATCH v2 12/16] btrfs: track running balance in a simpler way

On 04/20/2018 12:33 AM, David Sterba wrote: Currently fs_info::balance_running is 0 or 1 and does not use the semantics of atomics. The pause and cancel check for 0, that can happen only after __btrfs_balance exits for whatever reason. Parallel calls to balance ioctl may enter

Re: [PATCH v2.1 13/16] btrfs: move and comment read-only check in btrfs_cancel_balance

On 04/20/2018 08:06 PM, David Sterba wrote: Balance cannot be started on a read-only filesystem and will have to finish/exit before eg. going to read-only via remount. In case the filesystem is forcibly set to read-only after an error, balance will finish anyway and if the cancel call is too

Re: [PATCH 1/2] btrfs: improve balance kernel logs

On 04/26/2018 10:51 PM, Nikolay Borisov wrote: On 26.04.2018 11:01, Anand Jain wrote: Kernel logs are very important for the forensic investigations of the issues in general. This patch adds 'balance:' prefix so that it can be easily be searched and uses the block group names instead of its

Re: [PATCH 0/3] enhance btrfs_raid_array[]

On 04/26/2018 09:01 PM, David Sterba wrote: On Wed, Apr 25, 2018 at 07:01:41PM +0800, Anand Jain wrote: Cleanup patches as in the individual change log. These patches were sent independently as they aren't related as such, but as I am updating the 1/3 the 2/3 would endup with conflict. So

Re: Inconsistent behavior of fsync in btrfs

Hi Chris, Thanks for the response. We are using a tool we developed called CrashMonkey[1] to run crash consistency tests and generate the bug reports above. We'd be happy to guide you through setting up CrashMonkey and getting these bugs reproduced. However, if you want to be able to reproduce

Re: [PATCH 2/2] btrfs: add balance args info during start and resume

On Thu, Apr 26, 2018 at 04:01:29PM +0800, Anand Jain wrote: > Balance args info is an important information to be reviewed on the > system under audit. So this patch adds that. This kept annoying me. Thanks a lot! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!

Re: [PATCH 3/3] btrfs: qgroup, don't try to insert status item after ENOMEM in rescan worker

On 26.04.2018 22:23, je...@suse.com wrote: > From: Jeff Mahoney > > If we fail to allocate memory for a path, don't bother trying to > insert the qgroup status item. We haven't done anything yet and it'll > fail also. Just print an error and be done with it. > >

Re: [PATCH 2/3] btrfs: qgroups, remove unnecessary memset before btrfs_init_work

On 26.04.2018 22:23, je...@suse.com wrote: > From: Jeff Mahoney > > btrfs_init_work clears the work struct except for ->wq, so the memset > before calling btrfs_init_work in qgroup_rescan_init is unnecessary. > > We'll also initialize ->wq in btrfs_init_work so that it's

[PATCH 2/3] btrfs: qgroups, remove unnecessary memset before btrfs_init_work

From: Jeff Mahoney btrfs_init_work clears the work struct except for ->wq, so the memset before calling btrfs_init_work in qgroup_rescan_init is unnecessary. We'll also initialize ->wq in btrfs_init_work so that it's obvious. Signed-off-by: Jeff Mahoney ---

[PATCH 1/3] btrfs: qgroups, fix rescan worker running races

From: Jeff Mahoney Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but ended up reintroducing the hang-on-unmount bug that the commit it intended to fix addressed. The race this time is between

[PATCH 3/3] btrfs: qgroup, don't try to insert status item after ENOMEM in rescan worker

From: Jeff Mahoney If we fail to allocate memory for a path, don't bother trying to insert the qgroup status item. We haven't done anything yet and it'll fail also. Just print an error and be done with it. Signed-off-by: Jeff Mahoney --- fs/btrfs/qgroup.c | 2

Re: [PATCH v2] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Thu, Apr 26, 2018 at 09:27:43AM +0800, Liu Bo wrote: > path->keep_lock may force to lock tree root and higher nodes, and make > lock contention worse, thus it needs to be avoided as much as > possible. > > In btrfs_degrag_leaves, path->keep_lock is set but @path immediatley > gets released,

Re: Inconsistent behavior of fsync in btrfs

On 24 Apr 2018, at 20:35, Jayashree Mohan wrote: Hi, While investigating crash consistency bugs on btrfs, we came across workloads that demonstrate inconsistent behavior of fsync. Consider the following workload where fsync on the directory did not persist it. Only file B/foo gets

Re: [PATCH 1/2] btrfs: improve balance kernel logs

On 26.04.2018 11:01, Anand Jain wrote: > Kernel logs are very important for the forensic investigations of the > issues in general. This patch adds 'balance:' prefix so that it can be > easily be searched and uses the block group names instead of its bitmap. > > Signed-off-by: Anand Jain

Re: [PATCH 1/4] [RESEND] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction

On Wed, Apr 25, 2018 at 02:37:14AM +0300, Timofey Titovets wrote: > At now btrfs_dedupe_file_range() restricted to 16MiB range for > limit locking time and memory requirement for dedup ioctl() > > For too big input range code silently set range to 16MiB > > Let's remove that restriction by do

Re: [PATCH 4/4] [RESEND] Btrfs: reduce size of struct btrfs_inode

On Wed, Apr 25, 2018 at 02:37:17AM +0300, Timofey Titovets wrote: > Currently btrfs_inode have size equal 1136 bytes. (On x86_64). > > struct btrfs_inode store several vars releated to compression code, > all states use 1 or 2 bits. > > Lets declare bitfields for compression releated vars, to

Re: [PATCH] btrfs: trace: Add trace points for unused block groups

On Thu, Apr 26, 2018 at 05:17:20PM +0800, Qu Wenruo wrote: > This patch will add the following trace events: > 1) btrfs_remove_block_group >For btrfs_remove_block_group() function. >Triggered when a block group is really removed. > > 2) btrfs_add_unused_block_group >Triggered which

Re: [PATCH] btrfs: remove unused fs_info parameter

On Thu, Apr 26, 2018 at 03:49:02PM +0800, Gu Jinxiang wrote: > Since the commit below parameter fs_info in alloc_reloc_control > be no used. So remove it. > commit c6100a4b4e3d ("Btrfs: replace tree->mapping with > tree->private_data") > > Signed-off-by: Gu Jinxiang Added

Re: [PATCH] btrfs: trace: Remove unnecessary fs_info parameter for btrfs__reserve_extent event class

On Thu, Apr 26, 2018 at 09:27:11AM +0300, Nikolay Borisov wrote: > > > On 26.04.2018 09:24, Qu Wenruo wrote: > > fs_info can be extracted from btrfs_block_group_cache, and all > > btrfs_block_group_cache is created by btrfs_create_block_group_cache() > > with fs_info initialized, no need to

Re: [PATCH 0/3] enhance btrfs_raid_array[]

On Wed, Apr 25, 2018 at 07:01:41PM +0800, Anand Jain wrote: > Cleanup patches as in the individual change log. > > These patches were sent independently as they aren't related as such, > but as I am updating the 1/3 the 2/3 would endup with conflict. So > here I am putting all of them together

[PATCH] btrfs: trace: Add trace points for unused block groups

This patch will add the following trace events: 1) btrfs_remove_block_group For btrfs_remove_block_group() function. Triggered when a block group is really removed. 2) btrfs_add_unused_block_group Triggered which block group is added to unused_bgs list. 3) btrfs_skip_unused_block_group

Re: [PATCH] btrfs: remove unused fs_info parameter

On 04/26/2018 03:49 PM, Gu Jinxiang wrote: Since the commit below parameter fs_info in alloc_reloc_control be no used. So remove it. commit c6100a4b4e3d ("Btrfs: replace tree->mapping with tree->private_data") Signed-off-by: Gu Jinxiang Reviewed-by: Anand Jain

Re: [PATCH] btrfs: remove unused fs_info parameter

On 26.04.2018 10:49, Gu Jinxiang wrote: > Since the commit below parameter fs_info in alloc_reloc_control > be no used. So remove it. > commit c6100a4b4e3d ("Btrfs: replace tree->mapping with > tree->private_data") > > Signed-off-by: Gu Jinxiang Reviewed-by: Nikolay

[PATCH 2/2] btrfs: add balance args info during start and resume

Balance args info is an important information to be reviewed on the system under audit. So this patch adds that. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 153 +++-- 1 file changed, 150 insertions(+), 3 deletions(-)

[PATCH 1/2] btrfs: improve balance kernel logs

Kernel logs are very important for the forensic investigations of the issues in general. This patch adds 'balance:' prefix so that it can be easily be searched and uses the block group names instead of its bitmap. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 34

[PATCH 0/2] improve balance logs

Anand Jain (2): btrfs: improve balance kernel logs btrfs: add balance args info during start and resume fs/btrfs/volumes.c | 185 - 1 file changed, 169 insertions(+), 16 deletions(-) -- 2.7.0 -- To unsubscribe from this list: send the

[PATCH] btrfs: remove unused fs_info parameter

Since the commit below parameter fs_info in alloc_reloc_control be no used. So remove it. commit c6100a4b4e3d ("Btrfs: replace tree->mapping with tree->private_data") Signed-off-by: Gu Jinxiang --- fs/btrfs/relocation.c | 6 +++--- 1 file changed, 3 insertions(+), 3

Re: [PATCH] btrfs: trace: Remove unnecessary fs_info parameter for btrfs__reserve_extent event class

On 26.04.2018 09:24, Qu Wenruo wrote: > fs_info can be extracted from btrfs_block_group_cache, and all > btrfs_block_group_cache is created by btrfs_create_block_group_cache() > with fs_info initialized, no need to worry about NULL pointer > dereference. > > Signed-off-by: Qu Wenruo

[PATCH] btrfs: trace: Remove unnecessary fs_info parameter for btrfs__reserve_extent event class

fs_info can be extracted from btrfs_block_group_cache, and all btrfs_block_group_cache is created by btrfs_create_block_group_cache() with fs_info initialized, no need to worry about NULL pointer dereference. Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 8