Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On 2018年03月16日 12:01, Eryu Guan wrote: > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: >> Basic test case which triggers fsstress with dm-log-writes, and then >> check the fs after each FUA writes. >> With needed infrastructure and special handlers for journal based fs. > > It's

[PATCH v5 2/2] Remove false-positive VLAs when using max()

As part of removing VLAs from the kernel[1], we want to build with -Wvla, but it is overly pessimistic and only accepts constant expressions for stack array sizes, instead of also constant values. The max() macro triggers the warning, so this refactors these uses of max() to use the new

[PATCH v5 0/2] Remove false-positive VLAs when using max()

Patch 1 adds const_max_t(), patch 2 uses it in all the places max() was used for stack arrays. Commit log from patch 1: ---snip--- kernel.h: Introduce const_max_t() for VLA removal In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: > Basic test case which triggers fsstress with dm-log-writes, and then > check the fs after each FUA writes. > With needed infrastructure and special handlers for journal based fs. It's not clear to me why the existing infrastructure is

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Fri, Mar 16, 2018 at 12:49 AM, Kees Cook wrote: > On Thu, Mar 15, 2018 at 4:46 PM, Linus Torvalds > wrote: >> What I'm *not* so much ok with is "const_max(5,sizeof(x))" erroring >> out, or silently causing insane behavior due to hidden

Re: [PATCH 1/1] btrfs-progs: docs: annual typo, clarity, & grammar review & fixups

Hi Qu, So sorry for the incredibly delayed reply [it got lost in my drafts folder], I sincerely appreciate the time you took to respond. There is a lot in your responses that I suspect would benefit readers of the btrfs wiki, so I've drawn attention to them by replying inline. I've omitted the

[PATCH 1/1] btrfs-progs: Fix typos in docs and user-facing strings

Signed-off-by: Nicholas D Steeves --- Documentation/btrfs-balance.asciidoc | 2 +- Documentation/btrfs-check.asciidoc | 2 +- Documentation/btrfs-man5.asciidoc| 8 cmds-subvolume.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-)

[PATCH 0/1] btrfs-progs: Fix typos in docs and user-facing strings

Found with lintian and Emacs' writegood-mode. Cheers! Nicholas D Steeves (1): Fix typos in docs and user-facing strings Documentation/btrfs-balance.asciidoc | 2 +- Documentation/btrfs-check.asciidoc | 2 +- Documentation/btrfs-man5.asciidoc| 8 cmds-subvolume.c

Re: spurious full btrfs corruption

Hey. Found some time to move on with this: Frist, I think from my side (i.e. restoring as much as possible) I'm basically done now, so everything left over here is looking for possible bugs/etc. I have from my side no indication that my corruptions were actually a bug in btrfs... the new

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:46 PM, Linus Torvalds wrote: > What I'm *not* so much ok with is "const_max(5,sizeof(x))" erroring > out, or silently causing insane behavior due to hidden subtle type > casts.. Yup! I like it as an explicit argument. Thanks! -Kees --

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:46 PM, Linus Torvalds wrote: > > Well, the explicit typing allows that mixing, in that you can just > have "const_max_t(5,sizeof(x))" I obviously meant "const_max_t(size_t,5,sizeof(x))". Heh. Linus -- To unsubscribe from

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:41 PM, Kees Cook wrote: > > I much prefer explicit typing, but both you and Rasmus mentioned > wanting the int/sizeof_t mixing. Well, the explicit typing allows that mixing, in that you can just have "const_max_t(5,sizeof(x))" So I'm ok with

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:34 PM, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 3:46 PM, Kees Cook wrote: >> >> So, AIUI, I can either get strict type checking, in which case, this >> is rejected (which I assume there is still a desire to

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 3:46 PM, Kees Cook wrote: > > So, AIUI, I can either get strict type checking, in which case, this > is rejected (which I assume there is still a desire to have): > > int foo[const_max(6, sizeof(whatever))]; Ehh, yes, that looks fairly sane, and

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:17 PM, Miguel Ojeda wrote: >> The full one, using your naming convention: >> >> #define const_max(x, y) \ >> ({ \ >> if

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Fri, Mar 16, 2018 at 12:08 AM, Miguel Ojeda wrote: > On Thu, Mar 15, 2018 at 11:58 PM, Miguel Ojeda > wrote: >> On Thu, Mar 15, 2018 at 11:46 PM, Kees Cook wrote: >>> >>> By using this eye-bleed: >>> >>>

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 11:58 PM, Miguel Ojeda wrote: > On Thu, Mar 15, 2018 at 11:46 PM, Kees Cook wrote: >> >> By using this eye-bleed: >> >> size_t __error_not_const_arg(void) \ >> __compiletime_error("const_max() used with

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 11:46 PM, Kees Cook wrote: > On Thu, Mar 15, 2018 at 3:23 PM, Linus Torvalds > wrote: >> On Thu, Mar 15, 2018 at 3:16 PM, Kees Cook wrote: >>> >>> size_t __error_not_const_arg(void) \ >>>

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 3:23 PM, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 3:16 PM, Kees Cook wrote: >> >> size_t __error_not_const_arg(void) \ >> __compiletime_error("const_max() used with non-compile-time constant arg"); >> #define

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 3:16 PM, Kees Cook wrote: > > size_t __error_not_const_arg(void) \ > __compiletime_error("const_max() used with non-compile-time constant arg"); > #define const_max(x, y) \ >

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 2:42 PM, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 12:47 PM, Kees Cook wrote: >> >> To gain the ability to compare differing types, the arguments are >> explicitly cast to size_t. > > Ugh, I really hate this. > >

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 12:47 PM, Kees Cook wrote: > > To gain the ability to compare differing types, the arguments are > explicitly cast to size_t. Ugh, I really hate this. It silently does insane things if you do const_max(-1,6) and there is nothing in the name

Re: Btrfs broken in massive transfar

On Tue, Mar 13, 2018 at 10:56 PM, MASAKI haruka wrote: >> On Tue, Mar 13, 2018 at 1:25 PM, MASAKI haruka wrote: >> > journal(Kernel log), 7th try (to be readonly): >> > >> > --- >> > 3月 12 16:25:51 lily kernel: BTRFS info (device dm-6): creating UUID tree

Re: Crashes running btrfs scrub

On Thu, Mar 15, 2018 at 3:07 PM, Mike Stevens wrote: > Mar 15 14:03:06 auswscs9903 kernel: WARNING: CPU: 6 PID: 2720 at > fs/btrfs/extent-tree.c:10192 btrfs_create_pending_block_groups+0x1f3/0x260 > [btrfs] > Mar 15 14:03:06 auswscs9903 kernel: Modules linked in:

Re: Crashes running btrfs scrub

On Thu, Mar 15, 2018 at 12:58 PM, Mike Stevens wrote: > First, the required information > > ~ $ uname -a > Linux auswscs9903 3.10.0-693.21.1.el7.x86_64 For a kernel this old you kinda need to get support from the distro. This list is upstream and pretty much always

RE: Crashes running btrfs scrub

> That's a hell of a filesystem. RAID5 and RAID5 is unstable and should > not be used for anything but throw away data. You will be happy that you > value you data enough to have backups because all sensible sysadmins > do have backups correct?! (Do read just about any of Duncan's replies -

Re: Crashes running btrfs scrub

Mike Stevens wrote: First, the required information ~ $ uname -a Linux auswscs9903 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ~ $ btrfs --version btrfs-progs v4.9.1 ~ $ sudo btrfs fi show Label: none uuid:

Crashes running btrfs scrub

First, the required information ~ $ uname -a Linux auswscs9903 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ~ $ btrfs --version btrfs-progs v4.9.1 ~ $ sudo btrfs fi show Label: none uuid: 77afc2bb-f7a8-4ce9-9047-c031f7571150 Total

[PATCH v4 2/2] Remove false-positive VLAs when using max()

As part of removing VLAs from the kernel[1], we want to build with -Wvla, but it is overly pessimistic and only accepts constant expressions for stack array sizes, instead of also constant values. The max() macro triggers the warning, so this refactors these uses of max() to use the new

[PATCH v4 0/2] Remove false-positive VLAs when using max()

I'm calling this "v4" since the last effort at this was v3, even if it's a different approach. Patch 1 adds const_max(), patch 2 uses it in all the places max() was used for stack arrays. Commit log from patch 1: ---snip--- kernel.h: Introduce const_max() for VLA removal In the effort to remove

[PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

Re: [PATCH] btrfs: Verify extent allocated by find_free_extent() won't overlap with extents from previous transaction

On Thu, Mar 15, 2018 at 09:02:28AM +0800, Qu Wenruo wrote: > > The sanity tests are run at module load time, but the new check you are > > adding is a runtime one, so I think the right ifdef is > > CONFIG_BTRFS_DEBUG. > > I'll use CONFIG_BTRFS_DEBUG. > > But the patch is causing rcu problems

[PATCH v2] btrfs: drop fs_info parameter from btrfs_run_delayed_refs

It's provided by the trans handle Signed-off-by: Nikolay Borisov --- V2: Fixed some build failures. fs/btrfs/ctree.h | 2 +- fs/btrfs/extent-tree.c | 9 + fs/btrfs/inode.c | 4 +--- fs/btrfs/transaction.c | 23 +++ 4 files

[PATCH 4/4] btrfs: Drop fs_info parameter from __btrfs_run_delayed_refs

It's provided by trans handle Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 71d59ec02f08..89d640cb313e 100644 --- a/fs/btrfs/extent-tree.c

[PATCH 1/4] btrfs: drop fs_info parameter from btrfs_run_delayed_refs

It's provided by the trans handle Signed-off-by: Nikolay Borisov --- As discussed here https://www.spinics.net/lists/linux-btrfs/msg74775.html those were the last 3 remaining function called from btrfs_commit_transaction which were needlessly taking fs_info as an argument.

[PATCH 3/4] btrfs: Drop fs_info parameter from btrfs_finish_extent_commit

It's provided by the trans handle. Signed-off-by: Nikolay Borisov --- fs/btrfs/ctree.h | 3 +-- fs/btrfs/extent-tree.c | 4 ++-- fs/btrfs/transaction.c | 2 +- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index

[PATCH 2/4] btrfs: Drop fs_info parameter from btrfs_qgroup_account_extents

It's provided by the transaction handle. Signed-off-by: Nikolay Borisov --- fs/btrfs/qgroup.c | 6 +++--- fs/btrfs/qgroup.h | 3 +-- fs/btrfs/transaction.c | 4 ++-- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c

Re: [PATCH 1/2 v3] Btrfs-progs: check, fix false error reports for shared prealloc extents

On 14.03.2018 22:11, fdman...@kernel.org wrote: > From: Filipe Manana > > Under some cases the filesystem checker reports an error when it finds > checksum items for an extent that is referenced by an inode as a prealloc > extent. Such cases are not an error when the extent

[PATCH 3/8] btrfs: Remove unused tot_len var from lzo_decompress

Added already unused in a6fa6fae40ec ("btrfs: Add lzo compression support") Signed-off-by: Nikolay Borisov --- fs/btrfs/lzo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c index 6c7f18cd3b61..1c7f7f70caf4 100644 --- a/fs/btrfs/lzo.c +++

[PATCH 1/8] btrfs: Remove unused op_key var from add_delayed_refs

Added as part of 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees") but never used. tmp_op_key essentially subsumed that variable Signed-off-by: Nikolay Borisov --- fs/btrfs/backref.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff

[PATCH 0/8] Make the code -Wunused clean

This series eliminates all -Wunused warnings in the code base. Nikolay Borisov (8): btrfs: Remove unused op_key var from add_delayed_refs btrfs: Remove unused length var from scrub_handle_errored_block btrfs: Remove unused tot_len var from lzo_decompress btrfs: Remove unused root var

[PATCH 7/8] btrfs: Remove unused extent_root var from caching_thread

Added by b4570aa994b8 ("btrfs: fix compiling with CONFIG_BTRFS_DEBUG enabled.") and obsoleted by 2ff7e61e0d30 ("btrfs: take an fs_info directly when the root is not used otherwise") Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 2 -- 1 file changed, 2

[PATCH 4/8] btrfs: Remove unused root var from relink_file_extents

Added in 38c227d87c49 ("Btrfs: snapshot-aware defrag") but subsequently made redundant by 0b246afa62b0 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH 2/8] btrfs: Remove unused length var from scrub_handle_errored_block

Added in b5d67f64f9bc ("Btrfs: change scrub to support big blocks") but rendered redundant by be50a8ddaae1 ("Btrfs: Simplify scrub_setup_recheck_block()'s argument") Signed-off-by: Nikolay Borisov --- fs/btrfs/scrub.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH 5/8] btrfs: remove max_active var from open_ctree

Introduced by 5cdc7ad337fb ("btrfs: Replace fs_info->workers with btrfs_workqueue.") but obsoleted by 2a4581983f90 ("btrfs: factor btrfs_init_workqueues() out of open_ctree()") Signed-off-by: Nikolay Borisov --- fs/btrfs/disk-io.c | 3 --- 1 file changed, 3 deletions(-) diff

[PATCH 6/8] btrfs: Remove unused parent_level var from btrfs_realloc_node

Added by f2183bde1a91 ("Btrfs: Add BH_Defrag to mark buffers that are in need of defragging") but obsoleted by 3f157a2fd2ad ("Btrfs: Online btree defragmentation fixes") Signed-off-by: Nikolay Borisov --- fs/btrfs/ctree.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 8/8] btrfs: Remove unused flush var in shrink_delalloc

Added by 08e007d2e577 ("Btrfs: improve the noflush reservation") and made redundant by 17024ad0a0fd ("Btrfs: fix early ENOSPC due to delalloc") Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 5 - 1 file changed, 5 deletions(-) diff --git

[PATCH 2/2 v3] Btrfs-progs: add fsck test for filesystem with shared prealloc extents

From: Filipe Manana Verify that a filesystem check operation (fsck) does not report the following scenario as an error: An extent is shared between two inodes, as a result of clone/reflink operation, and for one of the inodes, lets call it inode A, the extent is referenced

[PATCH 1/2 v3] Btrfs-progs: check, fix false error reports for shared prealloc extents

From: Filipe Manana Under some cases the filesystem checker reports an error when it finds checksum items for an extent that is referenced by an inode as a prealloc extent. Such cases are not an error when the extent is actually shared (was cloned/reflinked) with other inodes

Re: [PATCH 1/2 v2] Btrfs-progs: check, fix false error reports for shared prealloc extents

On Thu, Mar 15, 2018 at 9:04 AM, Nikolay Borisov wrote: > > > On 14.03.2018 00:48, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> Under some cases the filesystem checker reports an error when it finds >> checksum items for an extent that is

Re: [PATCH 1/2 v2] Btrfs-progs: check, fix false error reports for shared prealloc extents

On 14.03.2018 00:48, fdman...@kernel.org wrote: > From: Filipe Manana > > Under some cases the filesystem checker reports an error when it finds > checksum items for an extent that is referenced by an inode as a prealloc > extent. Such cases are not an error when the extent

Re: Raid1 volume stuck as read-only: How to dump, recreate and restore its content?

Piotr Pawłow posted on Tue, 13 Mar 2018 08:08:27 +0100 as excerpted: > Hello, >> Put differently, 4.7 is missing a year and a half worth of bugfixes >> that you won't have when you run it to try to check or recover that >> btrfs that won't mount! Do you *really* want to risk your data on bugs >>

[RFC PATCH v2 8/8] btrfs-porgs: test: Add cli-test/009 to check subvolume list for both root and normal user

Signed-off-by: Tomohiro Misono --- tests/cli-tests/009-subvolume-list/test.sh | 136 + 1 file changed, 136 insertions(+) create mode 100755 tests/cli-tests/009-subvolume-list/test.sh diff --git

[RFC PATCH v2 6/8] btrfs-progs: sub list: Allow normal user to call "subvolume list/show"

Allow normal user to call "subvolume list/show" by using 3 new unprivileged ioctls (BTRFS_IOC_GET_SUBVOL_INFO, BTRFS_IOC_GET_SUBVOL_ROOTREF and BTRFS_IOC_INO_LOOKUP_USER). Note that for root, "subvolume list" returns all the subvolume in the filesystem by default, but for normal user, it returns

[RFC PATCH v2 7/8] btrfs-progs: test: Add helper function to check if test user exists

Test user 'progs-test' will be used to test the behavior of normal user. In order to pass this check, add the user by "useradd -M progs-test". Note that progs-test should not have root privileges. Signed-off-by: Tomohiro Misono --- tests/common | 10 ++

[RFC PATCH v2 4/8] btrfs-progs: sub list: Pass specified path down to btrfs_list_subvols()

This is a preparetion work to allow normal user to call "subvolume list/show". Signed-off-by: Tomohiro Misono --- btrfs-list.c | 16 +--- btrfs-list.h | 7 --- cmds-subvolume.c | 6 +++--- utils.c | 10 +- 4 files

[RFC PATCH v2 5/8] btrfs-progs: fallback to open without O_NOATIME flag in find_mount_root()

O_NOATIME flag requires effective UID of process matches file's owner or has CAP_FOWNER capabilities. Fallback to open without O_NOATIME flag so that normal user can also call find_mount_root(). This is a preparation work to allow normal user to call "subvolume show". Signed-off-by: Tomohiro

[RFC PATCH v2 2/8] btrfs-progs: ioctl: Add 3 definitions of new unprivileged ioctl

Add 3 definitions of new unprivileged ioctl (BTRFS_IOC_GET_SUBVOL_INFO, BTRFS_IOC_GET_SUBVOL_ROOTREF and BTRFS_IOC_INO_LOOKUP_USER). They will be used to implement user version of "btrfs subvolume list" etc. Signed-off-by: Tomohiro Misono --- ioctl.h | 86

[RFC PATCH v2 3/8] btrfs-progs: sub list: Add helper function which checks the permission for tree search ioctl

This is a preparetion work to allow normal user to call "subvolume list/show". Signed-off-by: Tomohiro Misono --- btrfs-list.c | 33 + btrfs-list.h | 1 + 2 files changed, 34 insertions(+) diff --git a/btrfs-list.c b/btrfs-list.c

[RFC PATCH v2 0/8] btrfs-progs: Allow normal user to call "subvolume list/show"

changelog: v1 -> v2 - add independent error handling patch (1st patch) - reimplement according to ioctl change - various cleanup === This RFC implements user version of "subvolume list/show" using three new ioctls. The ioctl patch to the kernel can be found in the ML titled "[PATCH v2

[RFC PATCH v2 1/8] btrfs-progs: sub list: Call rb_free_nodes() in error path

After btrfs_list_subvols() is called, root_lookup may hold some allocated memory area even if the function fails. Therefore rb_free_nodes() should be called. Signed-off-by: Tomohiro Misono --- btrfs-list.c | 16 1 file changed, 12 insertions(+),

[PATCH v2 3/3] btrfs: Add unprivileged version of ino_lookup ioctl

Add unprivileged version of ino_lookup ioctl BTRFS_IOC_INO_LOOKUP_USER to allow normal users to call "btrfs subvololume list/show" etc. in combination with BTRFS_IOC_GET_SUBVOL_INFO/BTRFS_IOC_GET_SUBVOL_ROOTREF. This can be used like BTRFS_IOC_INO_LOOKUP but the argument is different. This is

[PATCH v2 2/3] btrfs: Add unprivileged ioctl which returns subvolume's ROOT_REF

Add unprivileged ioctl BTRFS_IOC_GET_SUBVOL_ROOTREF which returns ROOT_REF information of the subvolume containing this inode. The min id of root ref's subvolume to be searched is specified by min_id in struct btrfs_ioctl_get_subvol_rootref_args. If there are more root refs than

[PATCH v2 1/3] btrfs: Add unprivileged ioctl which returns subvolume information

Add new unprivileged ioctl BTRFS_IOC_GET_SUBVOL_INFO which returns the information of subvolume containing this inode. (i.e. returns the information in ROOT_ITEM and ROOT_BACKREF.) Signed-off-by: Tomohiro Misono --- fs/btrfs/ioctl.c | 118

[PATCH v2 0/3] btrfs: Add three new unprivileged ioctls to allow normal users to call "sub list/show" etc.

changelog: v1 -> v2 - completely reimplement 1st/2nd ioctl to have user friendly api - various cleanup, remove unnecessary goto === This adds three new unprivileged ioctls: 1st patch: ioctl which returns subvolume information of ROOT_ITEM and ROOT_BACKREF 2nd patch: ioctl which returns

Re: High CPU usage of RT threads...

On 15.03.2018 09:23, Shyam Prasad N wrote: > Hi, > > Our servers run some daemons that are scheduled to run many real time > threads. These threads serve the client nodes by performing I/O on top > of some set of disks, configured as DRBD pairs with disks on other > peer servers for high

High CPU usage of RT threads...

Hi, Our servers run some daemons that are scheduled to run many real time threads. These threads serve the client nodes by performing I/O on top of some set of disks, configured as DRBD pairs with disks on other peer servers for high availability of data. Btrfs is the filesystem that is