On Tue, Feb 13, 2018 at 11:00:46AM +0800, Anand Jain wrote:
> Fixes the endianness bug in the fs_info::super_copy by using its
> btrfs_set_super...() function to set values in the SB, as these
> functions manage the endianness compatibility nicely.
Reviewed-by: Liu Bo
Thanks
>
> diff --git a/.gitignore b/.gitignore
> index 8e607f6e..272d53e4 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -43,6 +43,8 @@ libbtrfs.so.0.1
> library-test
> library-test-static
> /fssum
> +/libbtrfsutil.so*
> +/libbtrfsutil.a
>
.gitignore is no
On Wed, Feb 21, 2018 at 02:42:08PM +, Filipe Manana wrote:
> On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov wrote:
> >
> >
> > On 21.02.2018 15:51, Filipe Manana wrote:
> >> On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov
> >> wrote:
> >>> Currently the DIO read cases uses a botched idea
On Wed, Feb 21, 2018 at 04:15:38PM +0200, Nikolay Borisov wrote:
>
>
> On 21.02.2018 15:51, Filipe Manana wrote:
> > On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov wrote:
> >> Currently the DIO read cases uses a botched idea from ext4 to ensure
> >> that DIO reads don't race with truncate. Th
On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote:
> On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo wrote:
> > On Wed, Feb 21, 2018 at 02:42:08PM +, Filipe Manana wrote:
> >> On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov wrote:
> >> >
> >> >
On Thu, Feb 22, 2018 at 08:49:30AM +0200, Nikolay Borisov wrote:
>
>
> On 22.02.2018 00:38, Liu Bo wrote:
> > On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote:
> >> On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo wrote:
> >>> On Wed, Feb 21, 2018 at 0
On Thu, Feb 22, 2018 at 12:09:45PM -0700, Liu Bo wrote:
> On Thu, Feb 22, 2018 at 08:49:30AM +0200, Nikolay Borisov wrote:
> >
> >
> > On 22.02.2018 00:38, Liu Bo wrote:
> > > On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote:
> > >> On W
On Thu, Jan 11, 2018 at 09:25:50AM +0800, Anand Jain wrote:
> Support for a new command 'btrfs dev forget [dev]' is proposed here,
> to undo the effects of 'btrfs dev scan [dev]'. For this purpose,
> this patch proposes to use ioctl #5 as it was empty.
> IOW(BTRFS_IOCTL_MAGIC, 5, ..)
> This p
It doens't make sense to process prealloc extents as pages will be
filled with zero when reading prealloc extents.
Signed-off-by: Liu Bo
---
fs/btrfs/scrub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index ec56f33..9882513 1
On Wed, Feb 28, 2018 at 04:06:40PM +, Filipe Manana wrote:
> On Thu, Jan 25, 2018 at 6:02 PM, Liu Bo wrote:
> > The highest objectid, which is assigned to new inode, is decided at
> > the time of initializing fs roots. However, in cases where log replay
> > gets processe
On Thu, Mar 01, 2018 at 09:40:41PM +0200, Nikolay Borisov wrote:
>
>
> On 1.03.2018 21:04, Alex Adriaanse wrote:
> > On Feb 16, 2018, at 1:44 PM, Austin S. Hemmelgarn
> > wrote:
...
>
> > [496003.641729] BTRFS: error (device xvdc) in __btrfs_free_extent:7076:
> > errno=-28 No space left
> >
trees, but have different index, the log replay fails with
> an -EEXIST error when attempting to replay the inode reference from the
> log tree.
>
> Fix this by setting the last_unlink_trans field of the inode (our special
> file) to the current transaction id when a hard link is crea
On Wed, Feb 28, 2018 at 03:56:10PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If we have a file with 2 (or more) hard links in the same directory,
> remove one of the hard links, create a new file (or link an existing file)
> in the same directory with the name of the removed har
On Fri, Mar 02, 2018 at 11:29:33AM -0700, Liu Bo wrote:
> On Wed, Feb 28, 2018 at 03:56:10PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > If we have a file with 2 (or more) hard links in the same directory,
> > remove one of the hard links, cr
In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K)
as unit, however, scrub_extent() sets blocksize as unit, so rebuild
process may be triggered on every block on a same stripe.
A typical example would be that when we're replacing a disappeared disk,
all reads on the disks get
place we'd rather write what is stored in the
source device than the data calculuated from parity.
Signed-off-by: Liu Bo
---
fs/btrfs/scrub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 1b5ce2f..f449dc6 100644
async_missing_raid56() is identical to async_read_rebuild().
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index bb8a3c5..efb42dc 100644
--- a/fs/btrfs/raid56.c
+++ b/fs
Variable "success" is only checked when !sctx->is_dev_replace.
Signed-off-by: Liu Bo
---
fs/btrfs/scrub.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index e3203a1..1b5ce2f 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1
Rebuild on missing device is as same as recover, after it's done, rbio
has data which is consistent with on-disk data, so it can be cached to
avoid further reads.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/r
According to tlv_put()'s prototype, data and attrlen needs to be
exchanged in the macro, but seems all callers are already aware of
this misorder and are therefore not affected.
Signed-off-by: Liu Bo
---
fs/btrfs/send.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, Mar 06, 2018 at 11:47:47AM +0100, David Sterba wrote:
> On Fri, Mar 02, 2018 at 04:10:37PM -0700, Liu Bo wrote:
> > In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K)
> > as unit, however, scrub_extent() sets blocksize as unit, so rebuild
> > pro
Hi,
In the following steps[1], if on receiver side has got
changed via 'btrfs property set', then after doing incremental
updates, receiver gets a different snapshot from what sender has sent.
The reason behind it is that there is no change about file 'foo' in
the send stream, such that receiver
st of reads during rebuild can be
avoided, the parity recover calculation(xor or raid6 algorithms) needs to
be done $(BTRFS_STRIPE_LEN / blocksize) times.
This makes it smarter by doing raid56 scrub/replace on stripe length.
Signed-off-by: Liu Bo
---
v2: - Place bio allocation in code statement.
new inode
Signed-off-by: Liu Bo
---
tests/generic/481 | 75 +++
tests/generic/481.out | 5
tests/generic/group | 1 +
3 files changed, 81 insertions(+)
create mode 100755 tests/generic/481
create mode 100644 tests/generic/481.out
On Thu, Mar 08, 2018 at 10:07:33AM +, Filipe Manana wrote:
> On Wed, Mar 7, 2018 at 11:59 PM, Liu Bo wrote:
> > The regression is introduced to btrfs in linux v4.4 and it refuses to create
> > new files after log replay by returning -EEXIST.
> >
> > Although t
On Thu, Mar 08, 2018 at 09:15:50AM +0300, Andrei Borzenkov wrote:
> 07.03.2018 21:49, Liu Bo пишет:
> > Hi,
> >
> > In the following steps[1], if on receiver side has got
> > changed via 'btrfs property set', then after doing incremental
> > updates, r
On Tue, Mar 06, 2018 at 12:28:18PM +0100, David Sterba wrote:
> On Fri, Mar 02, 2018 at 04:10:38PM -0700, Liu Bo wrote:
> > Rebuild on missing device is as same as recover, after it's done, rbio
> > has data which is consistent with on-disk data, so it can be cached to
>
On Thu, Mar 08, 2018 at 03:29:48PM +, Filipe Manana wrote:
> On Wed, Mar 7, 2018 at 6:49 PM, Liu Bo wrote:
> > Hi,
> >
> > In the following steps[1], if on receiver side has got
> > changed via 'btrfs property set', then after doing incremental
> >
new inode
Reviewed-by: Filipe Manana
Signed-off-by: Liu Bo
---
v2: - Remove failed message from 481.out
- Drop the unnecessary write in creating a file
tests/generic/481 | 75 +++
tests/generic/481.out | 2 ++
tests/generic/group | 1
On Mon, Mar 12, 2018 at 07:28:26PM +0800, Eryu Guan wrote:
> On Sat, Mar 10, 2018 at 04:56:04PM -0700, Liu Bo wrote:
> > The regression is introduced to btrfs in linux v4.4 and it refuses to create
> > new files after log replay by returning -EEXIST.
> >
> > Although t
On Wed, Mar 14, 2018 at 8:03 AM, Edmund Nadolski wrote:
> This patch addresses an issue that causes fiemap to falsely
> report a shared extent. The test case is as follows:
>
> # cat do_xfs_io
> xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5
> sync
> xfs_io -c "fiemap
fers
> + * than @num_bytes only in the case of compressed
> extents.
> + *
> + * @num_bytes - Number of bytes to allocates on-disk.
> + *
> + * @min_alloc_size - Indicates the minimum amount of memory that the
Could you please pick another word instea
_fork+0x3a/0x50
>
> stack backtrace:
> CPU: 1 PID: 50 Comm: kswapd0 Tainted: GW4.12.14-kvmsmall #8
> SLE15 (unreleased)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.0.0-prebuilt.qemu-project.org 04/01/2014
> Call Trace:
> dump_stack+0x78/
On Thu, Mar 15, 2018 at 2:07 PM, Mike Stevens wrote:
>> 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 c
On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens wrote:
>> Could you please paste the whole dmesg, it looks like it hit
>> btrfs_abort_transaction(),
>> which should give us more information about where goes wrong.
>
> The whole thing is here https://pastebin.com/4ENq2saQ
Given this,
[ 299.410998]
On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo wrote:
> On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens
> wrote:
>>> Could you please paste the whole dmesg, it looks like it hit
>>> btrfs_abort_transaction(),
>>> which should give us more information about where goes wro
On Sun, Mar 18, 2018 at 3:52 PM, waxhead wrote:
> Liu Bo wrote:
>>
>> On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo wrote:
>>>
>>> On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens
>>> wrote:
>>>>>
>>>>> Could you please p
On Tue, Mar 20, 2018 at 7:01 PM, Qu Wenruo wrote:
>
>
> On 2018年03月21日 01:44, Mike Stevens wrote:
>>
30 devices is really not that much, heck you get 90 disks top load JBOD
storage chassis these days and BTRFS does sound like an attractive choice
for things like that.
>>
>>> So Mike
On Wed, Mar 21, 2018 at 9:50 AM, Menion wrote:
> Hi all
> I am trying to understand the status of RAID5/6 in BTRFS
> I know that there are some discussion ongoing on the RFC patch
> proposed by Liu bo
> But it seems that everything stopped last summary. Also it mentioned
> abou
Rebuild on missing device is as same as recover, after it's done, rbio
has data which is consistent with on-disk data, so it can be cached to
avoid further reads.
Signed-off-by: Liu Bo
Signed-off-by: Liu Bo
---
v2: Add comments to explain why REBUILD needs to be merged.
fs/btrfs/raid56.c
When mount fails to read trees like fs tree, checksum tree, extent
tree, etc, there is not enough information about where went wrong.
With this, messages like
"BTRFS warning (device sdf): failed to read root (objectid=7): -5"
would help us a bit.
Signed-off-by: Liu Bo
---
fs/btrfs
On Wed, Mar 28, 2018 at 11:24 PM, Nikolay Borisov wrote:
>
>
> On 29.03.2018 01:11, Liu Bo wrote:
>> When mount fails to read trees like fs tree, checksum tree, extent
>> tree, etc, there is not enough information about where went wrong.
>>
>> With this, messages
This is running in a typical write path, not inside a critical path
where we have to abort the running transaction, so it's OK to return
errors to callers and eventually to userspace.
Signed-off-by: Liu Bo
---
fs/btrfs/inode.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is
returned, path->nodes[0] could be NULL, log_dir_items lacks such a
check for <0 and we may run into a null pointer dereference panic.
Signed-off-by: Liu Bo
---
fs/btrfs/tree-log.c | 7 +--
1 file changed, 5 inse
, then only trans hanlde is marked as aborted while
BTRFS_FS_STATE_ERROR is not set, so resources remain in memory.
This makes btrfs also check BTRFS_FS_STATE_TRANS_ABORTED to make sure that
all resources won't stay in memory after umount.
Signed-off-by: Liu Bo
---
fs/btrfs/disk-io.c | 3
If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs
to bail out, otherwise @ret would be forced to be 0 after 'break;' and
the caller won't be aware of it.
Signed-off-by: Liu Bo
---
fs/btrfs/tree-log.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
On Sun, Apr 1, 2018 at 3:03 AM, Nikolay Borisov wrote:
>
>
> On 31.03.2018 01:11, Liu Bo wrote:
>> 0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is
>> returned, path->nodes[0] could be NULL, log_dir_items lacks such a
>> check for <0 and we
iewed-by: Nikolay Borisov
Signed-off-by: Liu Bo
---
v2: Add Fixes tag and reviewed-by.~
fs/btrfs/tree-log.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 4ee9431..11e2c26 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/bt
onous
operations")
Reviewed-by: Nikolay Borisov
Signed-off-by: Liu Bo
---
v2: Add Fixes tag and reviewed-by.
fs/btrfs/tree-log.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 4344577..4ee9431 100644
--- a/fs/btrfs/tre
On Thu, Apr 5, 2018 at 9:11 AM, David Sterba wrote:
> On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote:
>> Currently if some fatal errors occur, like all IO get -EIO, resources
>> would be cleaned up when
>> a) transaction is being committed or
>> b)
On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote:
> On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote:
>> This is running in a typical write path, not inside a critical path
>> where we have to abort the running transaction, so it's OK to return
>> errors to
On Fri, Apr 6, 2018 at 6:21 AM, David Sterba wrote:
> On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote:
>> On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote:
>> > On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote:
>> >> This is running in a typical wri
On Fri, Apr 6, 2018 at 10:43 AM, Liu Bo wrote:
> On Fri, Apr 6, 2018 at 6:21 AM, David Sterba wrote:
>> On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote:
>>> On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote:
>>> > On Sat, Mar 31, 2018 at 06:11:55AM +0800
On Wed, Apr 11, 2018 at 12:54 AM, Nikolay Borisov wrote:
> Currently this function handles both the READ and WRITE dio cases. This
> is facilitated by a bunch of 'if' statements, a goto short-circuit
> statement and a very perverse aliasing of "!created"(READ) case
> by setting lockstart = lockend
On Tue, Apr 10, 2018 at 5:12 AM, David Sterba wrote:
> On Mon, Apr 09, 2018 at 06:23:14PM -0700, Liu Bo wrote:
>> >>> As maybe_insert_hole is only called by btrfs_cont_expand here, which
>> >>> means it's a really hole, I don't expect drop_extents wou
On Fri, Apr 13, 2018 at 1:28 PM, Josef Bacik wrote:
> From: Josef Bacik
>
> Since we're allocating under atomic we could every easily enomem, so if
> that's the case and we can block then loop around and try to allocate
> the prealloc not under a lock.
>
> We also saw this happen during try_to_re
On Tue, Apr 17, 2018 at 03:34:04PM +0200, David Sterba wrote:
> On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote:
> > Currently if some fatal errors occur, like all IO get -EIO, resources
> > would be cleaned up when
> > a) transaction is being committed or
> > b)
achine:
>
> Kernel unaligned access at TPC[102f3080] btrfs_real_readdir+0x51c/0x718
> [btrfs]
>
Reviewed-by: Liu Bo
thanks,
liubo
> Fixes: 23b5ec74943 ("btrfs: fix readdir deadlock with pagefault")
> CC: sta...@vger.kernel.org # 4.14+
> Reported-and-tested-by: René Reb
path->keep_lock is set but @path immediatley gets released, this sets
->keep_lock only when it's necessary.
Signed-off-by: Liu Bo
---
fs/btrfs/tree-defrag.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/tree-defrag.c b/fs/btrfs/tree-defrag.c
index 3
On Thu, Apr 26, 2018 at 4:01 AM, David Sterba wrote:
> On Wed, Apr 25, 2018 at 09:40:34AM +0800, Liu Bo wrote:
>> path->keep_lock is set but @path immediatley gets released, this sets
>> ->keep_lock only when it's necessary.
>
> Can you please write down more
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, which is not necessary at all.
Signed-off-by: Liu Bo
---
v2:
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.
>>
&
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.
>>
&
On Fri, Nov 17, 2017 at 07:53:29PM +0800, Anand Jain wrote:
>
>
> On 11/17/2017 07:28 AM, Liu Bo wrote:
> > On Sun, Nov 12, 2017 at 06:56:50PM +0800, Anand Jain wrote:
> > > If the device is not present at the time of (-o degrade) mount
> > > the mount context w
On Wed, Nov 22, 2017 at 04:41:10PM +0200, Nikolay Borisov wrote:
>
>
> On 22.11.2017 02:35, Liu Bo wrote:
> > If the underlying protocal doesn't support retry and there are some
> > transient errors happening somewhere in our IO stack, we'd like to
> > giv
On Tue, Nov 28, 2017 at 08:22:36PM +0100, David Sterba wrote:
> On Tue, Nov 21, 2017 at 05:35:51PM -0700, Liu Bo wrote:
> > If the underlying protocal doesn't support retry and there are some
> > transient errors happening somewhere in our IO stack, we'd like to
> &
On Wed, Nov 29, 2017 at 03:11:14PM +0800, Anand Jain wrote:
> When the fist mirror failed to read we submit bio again to read from the
> 2nd mirror, however during this, we also set the flag REQ_FAILFAST_DEV
> which indicates to the underlying block device driver not to perform the
> default IO ret
On Wed, Nov 29, 2017 at 05:47:08PM +0100, David Sterba wrote:
> On Wed, Nov 29, 2017 at 12:09:29PM +0800, Anand Jain wrote:
> > On 11/29/2017 07:41 AM, p...@btrfs.list.sabi.co.uk wrote:
> > If the underlying protocal doesn't support retry and there
> > are some transient errors happening
't go away underneath us. So it can be
removed safely.
Signed-off-by: Liu Bo
---
fs/btrfs/scrub.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index e3f6c49..0cdf359 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scru
This test case is to reproduce a bug of raid6 reconstruction process.
The kernel fix are
Btrfs: do not merge rbios if their fail stripe index are not identical
Btrfs: make raid6 rebuild retry more
Signed-off-by: Liu Bo
---
tests/btrfs/155 | 119
Patch 1 is a simple cleanup.
Patch 2 fixes a bug in raid56 rbio merging code.
Patch 3 fixes a bug in raid6 reconstruction process which can end up
read failure when it can rebuild up good data.
Liu Bo (3):
Btrfs: remove redundant check in rbio_can_merge
Btrfs: do not merge rbios if their fail
ilures, if there is one
more failure besides the failure on which we're recovering, this can
always work.
The worst case is to retry as many times as the number of raid6 disks,
but given the fact that such a scenario is really rare in practice,
it's still acceptable.
Signed-off-by: Liu Bo
--
Given the above
'
if (last->operation != cur->operation)
return 0;
',
it's guaranteed that two operations are same.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/r
Since fail stripe index in rbio would be used to decide which
algorithm reconstruction would be run, we cannot merge rbios if
their's fail striped index are different, otherwise, one of the two
reconstructions would fail.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 9 +
1 file ch
The defined wait is not used anywhere.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 24a6222..62bcda2 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -670,7 +670,6 @@ static noinline int
On Tue, Dec 05, 2017 at 04:07:35PM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月05日 06:40, Liu Bo wrote:
> > There is a scenario that can end up with rebuild process failing to
> > return good content, i.e.
> > suppose that all disks can be read without problems and if th
On Tue, Dec 05, 2017 at 07:09:25PM +0100, David Sterba wrote:
> On Tue, Dec 05, 2017 at 04:07:35PM +0800, Qu Wenruo wrote:
> > > @@ -2166,11 +2166,21 @@ int raid56_parity_recover(struct btrfs_fs_info
> > > *fs_info, struct bio *bio,
> > > }
> > >
> > > /*
> > > - * reconstruct from the q st
On Wed, Dec 06, 2017 at 04:56:11PM +0800, Eryu Guan wrote:
> On Mon, Dec 04, 2017 at 03:33:23PM -0700, Liu Bo wrote:
> > This test case is to reproduce a bug of raid6 reconstruction process.
> >
> > The kernel fix are
> > Btrfs: do not merge rbios if their fail str
On Wed, Dec 06, 2017 at 08:11:30AM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月06日 06:55, Liu Bo wrote:
> > On Tue, Dec 05, 2017 at 07:09:25PM +0100, David Sterba wrote:
> >> On Tue, Dec 05, 2017 at 04:07:35PM +0800, Qu Wenruo wrote:
> >>>> @@ -2166,11 +2166
to
disable merge before doing IO.
Reported-by: Jérôme Carretero
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 5aa9d22..127c782 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btr
(Add Jérôme Carretero.)
Thanks,
-liubo
On Fri, Dec 08, 2017 at 04:02:35PM -0700, Liu Bo wrote:
> We're not allowed to take any new bios to rbio->bio_list in
> rbio_orig_end_io(), otherwise we may get merged with more bios and
> rbio->bio_list is not empty.
>
> This sh
On Sat, Dec 09, 2017 at 03:32:18PM +0200, Nikolay Borisov wrote:
>
>
> On 9.12.2017 01:02, Liu Bo wrote:
> > We're not allowed to take any new bios to rbio->bio_list in
> > rbio_orig_end_io(), otherwise we may get merged with more bios and
> > rbio->bio_l
Since fail stripe index in rbio would be used to decide which
algorithm reconstruction would be run, we cannot merge rbios if
their's fail striped index are different, otherwise, one of the two
reconstructions would fail.
Signed-off-by: Liu Bo
---
v2: Change to use if-else style.
fs/
d
> after the submit_bio returns and the bio is completed. In this
> particular instance this is not the case so there is no need to hold
> an extra reference since we directly return.
>
Looks good. If possible, please also drop other unnecessary bio_get()
in btrfs.
Reviewed-by: Liu
On Tue, Dec 12, 2017 at 07:52:38PM +0100, David Sterba wrote:
> On Mon, Dec 11, 2017 at 02:57:56PM -0800, Liu Bo wrote:
> > On Mon, Dec 11, 2017 at 04:38:48PM +0200, Nikolay Borisov wrote:
> > > This code was added in 492bb6deee34 ("Btrfs: Hold a reference on bios
> >
w
> is that the flush bio has a refcount of 2 and we only ever bio_put it
> once, leaving it to hang indefinitely. Fix this by removing the extra
> bio_get in __alloc_device.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Fixes: e0ae99941423 ("btrfs: preallocate device flush bio&qu
Patch 1-2 are some preparatory work.
Patch 3-5 are regression tests for handling EEXIST from adding extent map.
Patch 6-7 are fixing two bugs which can be reproduced by the above test cases.
Patch 8-10 are debugging wise, so that we can know what happened easily.
Liu Bo (10):
Btrfs: add he
This test case simulates the racy situation of dio write vs dio read,
and see if btrfs_get_extent() would return -EEXIST.
Signed-off-by: Liu Bo
---
fs/btrfs/tests/extent-map-tests.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/fs/btrfs/tests
This test case simulates the racy situation of buffered write vs dio
read, and see if btrfs_get_extent() would return -EEXIST.
Signed-off-by: Liu Bo
---
fs/btrfs/tests/extent-map-tests.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/fs/btrfs/tests
This is a subtle case, so in order to understand the problem, it'd be good to
know the content of existing and em when any error occurs.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_map.c b/fs/
racy situations.
Signed-off-by: Liu Bo
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/tests/btrfs-tests.c | 3 +
fs/btrfs/tests/btrfs-tests.h | 1 +
fs/btrfs/tests/extent-map-tests.c | 202 ++
4 files changed, 207 insertions(+), 1 deletion(-)
c
the existing em should be
returned, otherwise, we try our best to merge candidate em with
sibling ems to form a larger em.
Reported-by: David Vallender
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --g
ordingly, while for regular extent, em->block_len always
equals to em->len, hence this sets em->block_len with em->len.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
in
This is a prepare work for the following extent map selftest, which
runs tests against em merge logic.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.h | 2 ++
fs/btrfs/inode.c | 101 ++-
2 files changed, 58 insertions(+), 45 deletions(-)
diff
In order to debug subtle bugs around merge_extent_mapping(), perf probe
can be used to check the arguments, but sometimes merge_extent_mapping()
got inlined by compiler and couldn't be probed.
This is adding noinline attribute to merge_extent_mapping().
Signed-off-by: Liu Bo
---
fs/
This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the
subtle bugs around merge_extent_mapping.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.c| 1 +
include/trace/events/btrfs.h | 35 +++
2 files changed, 36 insertions(+)
diff
These helpers are extent map specific, this moves them to extent_map.c.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.h | 2 -
fs/btrfs/extent_map.c | 118 ++
fs/btrfs/extent_map.h | 2 +
fs/btrfs/inode.c | 117
On Sat, Dec 16, 2017 at 08:42:51AM +0200, Nikolay Borisov wrote:
>
>
> On 15.12.2017 21:58, Chris Mason wrote:
> > refcounts have a generic implementation and an asm optimized one. The
> > generic version has extra debugging to make sure that once a refcount
> > goes to zero, refcount_inc won't
On Fri, Dec 22, 2017 at 09:23:40AM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 00:42, Liu Bo wrote:
> > This is a prepare work for the following extent map selftest, which
> > runs tests against em merge logic.
> >
> > Signed-off-by: Liu Bo
> > ---
On Fri, Dec 22, 2017 at 09:42:17AM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 00:42, Liu Bo wrote:
> > We've observed that btrfs_get_extent() and merge_extent_mapping() could
> > return -EEXIST in several cases, and they are caused by some racy
> > cond
201 - 300 of 2564 matches
Mail list logo
