Re: [PATCH] btrfs: correct wrong comment about magic number of index_cnt

Sorry, the two patches are same. Please the latter one. Thanks, Su On 01/12/2018 11:08 AM, Su Yue wrote: There is no function named btrfs_get_inode_index_count. Explanation for magic number index_cnt=2 in btrfs_new_inode() is actually located in btrfs_set_inode_index_count(). So replace

[PATCH] btrfs: correct wrong comment about magic number of index_cnt

There is no function named btrfs_get_inode_index_count. Explanation for magic number index_cnt=2 in btrfs_new_inode() is actually located in btrfs_set_inode_index_count(). So replace 'btrfs_get_inode_index_count' in the comment by 'btrfs_set_inode_index_count'. Signed-off-by: Su Yue

[PATCH] btrfs: correct wrong comment about magic number of index_cnt

There is no function named btrfs_get_inode_index_count. Explanation for magic number index_cnt=2 in btrfs_new_inode() is actually located in btrfs_set_inode_index_count(). So replace 'btrfs_get_inode_index_count' in the comment by 'btrfs_set_inode_index_count'. Signed-off-by: Su Yue

Re: [PATCH bpf-next v4 5/5] error-injection: Support fault injection framework

2018-01-12 1:15 GMT+09:00 Masami Hiramatsu : > On Thu, 11 Jan 2018 23:44:57 +0900 > Akinobu Mita wrote: > >> 2018-01-11 9:51 GMT+09:00 Masami Hiramatsu : >> > Support in-kernel fault-injection framework via debugfs. >> > This

Re: [PATCH v5 00/19] fs: rework and optimize i_version handling in filesystems

On Tue, Jan 09, 2018 at 09:10:40AM -0500, Jeff Layton wrote: > From: Jeff Layton > > v5: > - don't corrupt refcounts stashed in i_version of ext4 xattr inodes > - add raw variants of inc and cmp functions, and have nfs use them > > v4: > - fix SB_LAZYTIME handling in

Re: Recommendations for balancing as part of regular maintenance?

On 01/10/2018 05:38 AM, Duncan wrote: > [...] > > And I've definitely noticed an effect since the ssd option stopped using > the 2 MiB spreading algorithm in 4.14. Glad to hear. :-) > In particular, while chunk usage > was generally stable before that and I only occasionally needed to run >

Re: Recommendations for balancing as part of regular maintenance?

On 01/10/2018 10:37 PM, waxhead wrote: > As just a regular user I would think that the first thing you would need > is an analyze that can tell you if it is a good idea to balance or not > in the first place. Tooling to create that is available. Btrfs allows you to read a lot of different data to

Re: [PATCH] btrfs: return 0 for success in btrfs_alloc_data_chunk_ondemand

On Wed, Jan 10, 2018 at 11:55:34AM -0500, Josef Bacik wrote: > From: Josef Bacik > > My delayed refs rsv patches uncovered a problem in > btrfs_alloc_data_chunk_ondemand where we don't clear ret before > returning, so we could have whatever left over value we had from trying > to

Re: [PATCH v5 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed

Hi Jeff, On Tue, Jan 09, 2018 at 09:10:58AM -0500, Jeff Layton wrote: > From: Jeff Layton > > At this point, we know that "now" and the file times may differ, and we > suspect that the i_version has been flagged to be bumped. Attempt to > bump the i_version, and only mark

Re: [PATCH] btrfs: Make btrfs_inode_rsv_release static

On Thu, Jan 11, 2018 at 03:46:44PM +0200, Nikolay Borisov wrote: > It's not used outside of extent-tree so there is no reason to not be > static. > > Signed-off-by: Nikolay Borisov Added to 4.16 queue, thanks. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH bpf-next v4 3/5] error-injection: Separate error-injection from kprobe

On Thu, Jan 11, 2018 at 09:50:24AM +0900, Masami Hiramatsu wrote: > Since error-injection framework is not limited to be used > by kprobes, nor bpf. Other kernel subsystems can use it > freely for checking safeness of error-injection, e.g. > livepatch, ftrace etc. > So this separate

Re: [PATCH bpf-next v4 5/5] error-injection: Support fault injection framework

On Thu, 11 Jan 2018 23:44:57 +0900 Akinobu Mita wrote: > 2018-01-11 9:51 GMT+09:00 Masami Hiramatsu : > > Support in-kernel fault-injection framework via debugfs. > > This allows you to inject a conditional error to specified > > function using

Re: [PATCH bpf-next v4 5/5] error-injection: Support fault injection framework

2018-01-11 9:51 GMT+09:00 Masami Hiramatsu : > Support in-kernel fault-injection framework via debugfs. > This allows you to inject a conditional error to specified > function using debugfs interfaces. > > Here is the result of test script described in >

[PATCH] btrfs: Make btrfs_inode_rsv_release static

It's not used outside of extent-tree so there is no reason to not be static. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index

Re: [PATCH] btrfs: return 0 for success in btrfs_alloc_data_chunk_ondemand

On 10.01.2018 18:55, Josef Bacik wrote: > From: Josef Bacik > > My delayed refs rsv patches uncovered a problem in > btrfs_alloc_data_chunk_ondemand where we don't clear ret before > returning, so we could have whatever left over value we had from trying > to do a chunk

Re: Recommendations for balancing as part of regular maintenance?

On 2018-01-10 15:44, Timofey Titovets wrote: 2018-01-10 21:33 GMT+03:00 Tom Worster : On 10 Jan 2018, at 12:01, Austin S. Hemmelgarn wrote: On 2018-01-10 11:30, Tom Worster wrote: Also, for future reference, the term we typically use is ENOSPC, as that's the symbolic name

Re: Recommendations for balancing as part of regular maintenance?

On 2018-01-10 16:37, waxhead wrote: Austin S. Hemmelgarn wrote: So, for a while now I've been recommending small filtered balances to people as part of regular maintenance for BTRFS filesystems under the logic that it does help in some cases and can't really hurt (and if done right, is really

Re: recommendations and contraindications of using btrfs for Oracle Database Server

On Thu, Jan 11, 2018 at 6:23 PM, Nikolay Borisov wrote: > > > On 11.01.2018 12:51, Ext-Strii-Houttemane Philippe wrote: >> Hello, >> >>We are using btrfs filesystem on local disks (RAID 1) as underlying >> filesystem to host our Oracle 12c datafiles. >> This allow us to

Re: recommendations and contraindications of using btrfs for Oracle Database Server

I'd advice to migrate from this configuration ASAP. Each of the following is enough reason to do so: 1. Running BTRFS on top of kernel 3.10 (there can be vendor backports, but most likely they only include absolutely critical fixes for the BTRFS part, not the whole stuff). And RedHat (that's

Re: recommendations and contraindications of using btrfs for Oracle Database Server

On 11.01.2018 12:51, Ext-Strii-Houttemane Philippe wrote: > Hello, > >We are using btrfs filesystem on local disks (RAID 1) as underlying > filesystem to host our Oracle 12c datafiles. > This allow us to cold backup databases via snapshot in a few seconds and > benefit from higher

recommendations and contraindications of using btrfs for Oracle Database Server

Hello, We are using btrfs filesystem on local disks (RAID 1) as underlying filesystem to host our Oracle 12c datafiles. This allow us to cold backup databases via snapshot in a few seconds and benefit from higher performance than over Linux filesystem formats. This is the problem we meet:

[PATCH v2 1/2] btrfs-progs: do less aggressive btree readahead

Update btrfs-progs to match kernel sources. Reference: commit a717531942f4 ("Btrfs: do less aggressive btree readahead") Signed-off-by: Gu JinXiang --- ctree.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/ctree.c b/ctree.c index

[PATCH v2 2/2] btrfs-progs: cleanup, use enum values for btrfs_path reada

Update btrfs-progs to match kernel sources Reference: commit e4058b54d1e4 ("btrfs: cleanup, use enum values for btrfs_path reada") Signed-off-by: Gu Jinxiang --- cmds-restore.c| 4 ++-- ctree.c | 13 ++--- ctree.h | 2 +- extent-tree.c

[PATCH v2 0/2] btrfs-progs: Update btrfs-progs to match kernel sources

v2->v1: Modify btrfs-progs by refer to the two patches list below: commit a717531942f4 ("Btrfs: do less aggressive btree readahead") commit e4058b54d1e4 ("btrfs: cleanup, use enum values for btrfs_path reada") Gu Jinxiang (2): btrfs-progs: do less aggressive btree readahead btrfs-progs:

[PATCH v2] generic/015: Change the test filesystem size to 101mb

This test has been failing for btrfs for quite some time, at least since 4.7. There are 2 implementation details of btrfs that it exposes: 1. Currently btrfs filesystem under 100mb are created in Mixed block group mode. Freespace accounting for it is not 100% accurate - I've observed consistent

Re: Recommendations for balancing as part of regular maintenance?

Austin S. Hemmelgarn posted on Wed, 10 Jan 2018 12:01:42 -0500 as excerpted: >> - Some experienced users say that, to resolve a problem with DoUS, they >> would rather recreate the filesystem than run balance. > This is kind of independent of BTRFS. A lot of seasoned system > administrators are

Re: [PATCH v3 1/2] btrfs: use enum instead of constant value

On 11.01.2018 10:12, Gu Jinxiang wrote: > populate_free_space_tree calls function btrfs_search_slot_for_read with > parameter int find_higher = 1, it means that, if no exact match is found, > then use the next higher item. > So in function populate_free_space_tree, use READA_FORWARD to read >

Re: [PATCH v3 2/2] btrfs: use enum instead of constant value

On 11.01.2018 10:12, Gu Jinxiang wrote: > From: Gu JinXiang > > load_free_space_tree calls either function load_free_space_bitmaps or > load_free_space_extents. And either of those two will lead to call > btrfs_next_item. > So in function load_free_space_tree, use

[PATCH v3 2/2] btrfs: use enum instead of constant value

From: Gu JinXiang load_free_space_tree calls either function load_free_space_bitmaps or load_free_space_extents. And either of those two will lead to call btrfs_next_item. So in function load_free_space_tree, use READA_FORWARD to read forward ahead. Changelog: v2->v1:

[PATCH v3 1/2] btrfs: use enum instead of constant value

populate_free_space_tree calls function btrfs_search_slot_for_read with parameter int find_higher = 1, it means that, if no exact match is found, then use the next higher item. So in function populate_free_space_tree, use READA_FORWARD to read forward ahead. Changelog: v2->v1: change enum from

Re: hang in btrfs_async_reclaim_metadata_space

On 11.01.2018 05:03, Adam Borowski wrote: > On Sun, Jan 07, 2018 at 01:17:19PM +0200, Nikolay Borisov wrote: >> On 6.01.2018 07:10, Adam Borowski wrote: >>> Hi! >>> I got a reproducible infinite hang, reliably triggered by the testsuite of >>> "flatpak"; fails on at least 4.15-rc6, 4.9.75, and

[PATCH v2] fstests: filter: Introduce filter to filter out offset for xfs_io

Some test cases (AFAIK, btrfs RAID recovery test cases) read out certain location to verify its data. Such read is mostly OK, but the golden output contains the on-disk offset, which can differ due to underlying chunk change. (This time is mkfs chunk layout change for btrfs) So introduce macro