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 'btrfs
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
---
fs/btrf
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
---
fs/btrf
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 allows you to inject a conditional error to specified
>> > function usin
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 generic_update_time
> - add
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
> b
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
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 do a chunk alloc
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 the inode dirty if that
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 linux-btrfs" in
the body
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 error-injection
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 debugfs interfaces.
> >
> > Here is the result of te
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
> Documentation/fault-injection/fault-injectio
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 b9c72c35e457..271f13bad41a 100644
--- a
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 allocation or whatever t
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 for the error code y
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 in
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 cold backup databases
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 y
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 performa
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: Ora
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 4fc33b14..361e53a8 100
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: cleanu
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 | 12 ++--
fre
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 1m
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
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
> for
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 READA_FORWARD to read forward
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: change enum from READA_BACK
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 REA
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 o
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 _f
32 matches
Mail list logo
