ordingly, and 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/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index e1a7f3c..278
+
start
As we can see, it turns out that if start is within existing em (front
inclusive), then the existing em should be returned as is, otherwise,
we try our best to merge candidate em with sibling ems to form a
larger em (in order to reduce the total number of em).
Repor
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| 3 +++
include/trace/events/btrfs.h | 35 +++
2 files changed, 38 insertions(+)
di
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 | 80
2 files changed, 48 insertions(+), 34 deletions(-)
diff
On Thu, Jan 04, 2018 at 09:47:56AM -0800, Liu Bo wrote:
> On Wed, Jan 03, 2018 at 09:52:43PM +0800, Anand Jain wrote:
> > bio_add_page() can fail for logical reasons as from the bio_add_page()
> > comments:- 'This will only fail if either
> > bio->bi_vcnt == bio->
On Wed, Jan 03, 2018 at 09:52:43PM +0800, Anand Jain wrote:
> bio_add_page() can fail for logical reasons as from the bio_add_page()
> comments:- 'This will only fail if either
> bio->bi_vcnt == bio->bi_max_vecs or it's a cloned bio.' Don't inc the
> write error statistics for this. And set -EINVAL
On Thu, Jan 04, 2018 at 05:05:34PM +0800, Eryu Guan wrote:
> On Tue, Jan 02, 2018 at 01:35:00PM -0700, Liu Bo wrote:
> > This is to reproduce a bug of scrub, with which scrub is unable to
> > repair raid6 corruption as expected.
> >
> > The kernel side fixes are
>
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
--
normal reads to rebuild raid6 correctly with more retries
in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix
scrub to do the exactly same rebuild process.
[1]: https://patchwork.kernel.org/patch/10091755/
Signed-off-by: Liu Bo
---
fs/btrfs/scrub.c | 44 ++
This is to reproduce a bug of scrub, with which scrub is unable to
repair raid6 corruption as expected.
The kernel side fixes are
Btrfs: make raid6 rebuild retry more
Btrfs: fix scrub to repair raid6 corruption
Signed-off-by: Liu Bo
---
tests/btrfs/158 | 114
On Wed, Dec 20, 2017 at 11:59:20PM +0300, Timofey Titovets wrote:
> How reproduce:
> touch test_file
> chattr +C test_file
> dd if=/dev/zero of=test_file bs=1M count=1
> btrfs fi def -vrczlib test_file
> filefrag -v test_file
>
> test_file
> Filesystem type is: 9123683e
> File size of test_file is
On Sat, Dec 30, 2017 at 11:32:04PM +0300, Timofey Titovets wrote:
> Currently btrfs raid1/10 balancer bаlance requests to mirrors,
> based on pid % num of mirrors.
>
> Make logic understood:
> - if one of underline devices are non rotational
> - Queue leght to underline devices
>
> By default t
On Sat, Dec 23, 2017 at 09:39:00AM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 21:07, Liu Bo wrote:
> > On Fri, Dec 22, 2017 at 10:56:31AM +0200, Nikolay Borisov wrote:
> >>
> >>
> >> On 22.12.2017 00:42, Liu Bo wrote:
> >>> This is add
In fact nobody is waiting on @wait's waitqueue, it can be safely
removed.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/raid56.c | 10 --
2 files changed, 11 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 13c260b..b2e09fe 100644
--- a/fs/
extra
> check for zero refcounts before radix tree deletion.
> btrfs_get_delayed_node() was the only path that was allowing refcounts
> to go from zero to one.
>
Reviewed-by: Liu Bo
-liubo
> Signed-off-by: Chris Mason
> Fixes: 6de5f18e7b0da
> cc: #4.12+
> ---
> fs/bt
On Fri, Dec 22, 2017 at 02:10:45PM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 00:42, Liu Bo wrote:
> > This fixes a corner case that is caused by a race of dio write vs dio
> > read/write.
> >
> > dio write:
> > [0, 32k) -> [0, 8k) + [8k, 32
On Fri, Dec 22, 2017 at 10:56:31AM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 00:42, Liu Bo wrote:
> > This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the
> > subtle bugs around merge_extent_mapping.
>
> In the next patch you are al
On Fri, Dec 22, 2017 at 09:51:24AM +0200, Nikolay Borisov wrote:
>
>
> On 22.12.2017 00:42, Liu Bo wrote:
> > This test case simulates the racy situation of buffered write vs dio
> > read, and see if btrfs_get_extent() would return -EEXIST.
>
> Isn't mixing
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
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 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
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
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
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 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
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
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
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
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
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
> >
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
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/
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
(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
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
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
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 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 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
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
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
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
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
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
'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
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
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 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 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 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 Mon, Nov 20, 2017 at 02:00:07AM -0500, Jérôme Carretero wrote:
> Hi,
>
>
>
> This was while doing a "userspace scrub" with "tar c":
>
> [633250.707455] btrfs_print_data_csum_error: 14608 callbacks suppressed
> [633250.707459] BTRFS warning (device dm-18): csum failed root 5 ino 1376 off
> 3
retry write on errors _sector by sector_ in order to
find out which sector is really bad so that we can mark it somewhere.
And since endio is running in interrupt context, the real retry work
is scheduled in system_unbound_wq in order to get a normal context.
Signed-off-by: Liu Bo
---
fs/btrfs/
Because rbio will be bio->private in any case, we can remove @rbio in
arguments.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 24a6222..aa04e5b 100644
--- a/fs/bt
te IO,
the above two parts need to be split.
This add a helper __btrfs_end_bio() to do the second part.
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 60 +++---
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/b
ded badblocks support, patch 7 changes it back to retry the whole
bio. (I didn't fold patch 7 to patch 3 in the hope of just reverting
patch 7 once badblocks support is done, but I'm open to it.)
Liu Bo (7):
Btrfs: keep a copy of bi_iter in btrfs_io_bio
Btrfs: add helper __btrfs_end
Since we haven't included badblocks support in our retry path, instead
of retry sector by sector only retry the whole bio to give it an extra
chance.
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 72 ++
1 file changed, 13 insertions(+
Retry writes on raid56's final full stripe writes in order to get over
some transient errors in our IO stack.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/
We'd like to retry write on errors, so this splits raid_write_end_io()
to two parts, a) checking errors and b) the rest in a helper
__raid_write_end_io().
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git
ed bio and normal bio in the same way.
This keeps a copy of bi_iter in btrfs_io_bio before we submit bio so
that in endio we can iter the bio with bio_for_each_segment() only.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c | 2 --
fs/btrfs/volumes.c | 3 ++-
2 files changed, 2 insertions(+), 3
lso reported this while testing against his fsync error
patch set[1].
[1]: https://www.spinics.net/lists/linux-btrfs/msg65308.html
"btrfs list corruption and soft lockups while testing writeback error handling"
Fixes: 8407f553268a4611f254 ("Btrfs: fix data corruption after fast fsyn
On Mon, Nov 20, 2017 at 06:34:34PM +0100, David Sterba wrote:
> On Mon, Nov 13, 2017 at 10:57:24AM -0700, Liu Bo wrote:
> > Xfstests btrfs/146 revealed this corruption,
> >
> > [ 58.138831] Buffer I/O error on dev dm-0, logical block 2621424, async
> > page read
>
t; during the next fsync. Replace the WARN_ON with a ratelimited pr_crit
> so that the developers have /some/ kind of breadcrumb to track down the
> offending program(s) and file(s) involved.
>
Looks good to me, thanks for addressing the warning.
Reviewed-by: Liu Bo
Thanks,
-liubo
>
On Thu, Nov 16, 2017 at 01:45:51PM -0800, Marc MERLIN wrote:
> On Thu, Nov 16, 2017 at 06:27:44PM +0100, Holger Hoffstätte wrote:
> > On 11/16/17 18:07, Marc MERLIN wrote:
> > > Sorry, was missing the kernel number in the subject, just fixed that.
> > >
> > > On Thu, Nov 16, 2017 at 09:04:45AM -08
On Tue, Nov 14, 2017 at 04:56:56PM -0500, Josef Bacik wrote:
> From: Josef Bacik
>
> Now that the only thing that keeps eb's alive is io_pages and it's
> refcount we need to hold the eb ref for the entire end io call so we
> don't get it removed out from underneath us. Also the hooks make no
> s
On Tue, Nov 14, 2017 at 04:56:55PM -0500, Josef Bacik wrote:
> From: Josef Bacik
>
> In order to more efficiently support sub-page blocksizes we need to stop
> allocating pages from pagecache for our metadata. Instead switch to using the
> account_metadata* counters for making sure we are keepin
f them, so convert them to count bytes written/dirtied, and allow the
> metadata accounting stuff to change the counters as well.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Signed-off-by: Josef Bacik
> Acked-by: Tejun Heo
> ---
> fs/fuse/file.c | 4 +
inode of interest
> + *
> + * Does the inode have cgroup writeback support.
> + */
> +static inline bool inode_cgwb_enabled(struct inode *inode)
> +{
> + return bdi_cgwb_enabled(inode_to_bdi(inode), inode->i_sb);
> }
>
> /**
> @@ -389,6 +400,12 @@ static inline vo
On Wed, Nov 15, 2017 at 06:42:06PM +0100, David Sterba wrote:
> There are now 20 bytes of holes, we can reduce that to 4 by minor
> changes. Moving 'aborted' to the status and flags is also more logical,
> similar for num_dirty_bgs. The size goes from 432 to 416.
>
Review
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 will create a dummy missing struct btrfs_device.
> Later this device may reappear after the FS is mounted.
This commit log doesn't explain what would hap
ipped and
> fallback to old btrfs_check_leaf() behavior.
>
> So we can still get early warning if we screw up item pointers, and
> avoid false panic.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Cc: Filipe Manana
> Reported-by: Lakshmipathi.G
> Signed-off-by: Qu We
On Wed, Nov 08, 2017 at 09:59:39AM +0200, Nikolay Borisov wrote:
>
>
> On 8.11.2017 02:54, Qu Wenruo wrote:
> > Add checker for dir item, for key types DIR_ITEM, DIR_INDEX and
> > XATTR_ITEM.
> >
> > This checker does comprehensive check for:
> > 1) dir_item header and its data size
> >Agai
Nikolay Borisov
Signed-off-by: Liu Bo
---
v2: Change 'fadvise -d' to _scratch_cycle_mount.
To Nikolay,
I didn't add your tested-by, but could you please verify if this also
works on your test box?
tests/btrfs/143 | 20 ++--
1 file changed, 10 insertions(+), 10
ta chunk before
relocating the data chunk.
Metadata/System chunk are supposed to have non-zero bytes all the time
so their raid profile is preserved.
Reported-by: James Alandt
Signed-off-by: Liu Bo
---
v3: More details about how losing data profile happens.
v2: - return the correct error.
- mov
each disk so that we can save several disk access.
Moreover, fsync issues synchronous writes, so plug can really take
effect.
Signed-off-by: Liu Bo
---
v2: Explain why setting plug makes sense.
fs/btrfs/file.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/
On Wed, Nov 15, 2017 at 04:20:52PM -0500, Josef Bacik wrote:
> From: Josef Bacik
>
> If we fail to prepare our pages for whatever reason (out of memory in
> our case) we need to make sure to drop the block_group->data_rwsem,
> otherwise hilarity ensues.
>
Reviewed-by: Liu
xAV8aTYBSiI06pb3WZoiRJW8Vo1L3NQ&e=
> > >
> > > It may be that they are a contributing factor, but this smells more like
> > > a bug down in btrfs. Let me know if you need other info:
>
> [ btrfs inode logging ]
>
> > (cc'ing Liu Bo since we
lso reported this while testing against his fsync error
patch set[1].
[1]: https://www.spinics.net/lists/linux-btrfs/msg65308.html
"btrfs list corruption and soft lockups while testing writeback error handling"
Signed-off-by: Liu Bo
---
fs/btrfs/file.c | 1 +
fs/btrfs/tree-log.c |
each disk so that we can save several disk access.
Moreover, fsync issues synchronous writes, so plug can really take
effect.
Signed-off-by: Liu Bo
---
fs/btrfs/file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e43da6c..063180b 100644
--- a/fs/
On Thu, Nov 09, 2017 at 05:29:25PM +0800, Anand Jain wrote:
>
>
> On 11/09/2017 03:53 AM, Liu Bo wrote:
> >On Tue, Nov 07, 2017 at 04:32:55PM +0800, Anand Jain wrote:
> >>
> >>
> >>On 11/02/2017 08:54 AM, Liu Bo wrote:
> >>>With raid6
On Tue, Nov 07, 2017 at 04:32:55PM +0800, Anand Jain wrote:
>
>
> On 11/02/2017 08:54 AM, Liu Bo wrote:
> >With raid6 profile, btrfs can end up with data corruption by the
> >following steps.
> >
> >Say we have a 5 disks that are set up with raid6 profile,
>
On Mon, Nov 06, 2017 at 05:40:25PM +0100, David Sterba wrote:
> On Wed, Nov 01, 2017 at 06:54:02PM -0600, Liu Bo wrote:
> > Here we have defined two flags,
> > - Fautly
> > - In_sync
> >
> > Currently only In_sync is in use, it only matters when device serves
&g
Adding __init macro gives kernel a hint that this function is only
used during the initialization phase and its memory resources can be
freed up after.
Signed-off-by: Liu Bo
---
fs/btrfs/compression.h | 2 +-
fs/btrfs/ctree.h | 6 +++---
fs/btrfs/delayed-ref.c | 2 +-
fs/btrfs/delayed
On Tue, Oct 31, 2017 at 07:53:47AM +0800, Qu Wenruo wrote:
>
>
> On 2017年10月31日 01:14, Liu Bo wrote:
> > First and foremost, here are the problems we have right now,
> >
> > a) %thread_pool is configurable via mount option, however for those
> >'worker
On Thu, Nov 02, 2017 at 11:49:52PM +0800, Eryu Guan wrote:
> On Wed, Nov 01, 2017 at 06:01:23PM -0600, Liu Bo wrote:
> > This is to reproduce a raid6 reconstruction bug after two drives
> > getting offline and online via hotplug.
> >
> > Signed-off-by: James Alandt
last valid generation can be retained through several reboot,
btrfs is able to detect the out-of-sync device.
Signed-off-by: Liu Bo
---
fs/btrfs/disk-io.c | 21 -
fs/btrfs/volumes.c | 47 ---
fs/btrfs/volumes.h | 8
3 files ch
log.
This changes it to set In_sync flag after iterating all devices, at
this point we have the latest device so we can report out-of-sync
device precisely.
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
27;,
all data on a device might be stale if 'In_sync' has not been set.
With this, we can build the correct data2 from parity P, Q and data1.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/rai
://patchwork.kernel.org/patch/10037769/
Liu Bo (4):
Btrfs: introduce device flags
Btrfs: fix data corruption in raid6
Btrfs: make raid1 and raid10 be aware of device flag In_sync
Btrfs: change how we set In_sync
fs/btrfs/disk-io.c | 21 -
fs/btrfs/raid56.c | 3 ++-
fs/btrfs/volumes.c
If a device is not in_sync, avoid reading data from it as data on it
might be stale.
Although checksum can detect stale data so we won't return stale data
to users , this helps us read the good copy directly.
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 23 ---
1
This is to reproduce a raid6 reconstruction bug after two drives
getting offline and online via hotplug.
Signed-off-by: James Alandt
Signed-off-by: Liu Bo
---
tests/btrfs/152 | 121 ++
tests/btrfs/group | 1 +
2 files changed, 122
These rules have been hidden in several if-else and are not
straightforward to follow, for example, dio submit hook's nocsum case
has a bug , i.e. doing async submit instead of sync submit, which has
been fixed recently.
This is documenting the rules for reference.
Signed-off-by: Liu Bo
--
On Tue, Oct 31, 2017 at 10:23:30PM +0200, Nikolay Borisov wrote:
>
>
> On 30.10.2017 19:14, Liu Bo wrote:
> > If a file's DIR_ITEM key is invalid (due to memory errors) and gets
> > written to disk, a future lookup_path can end up with kernel panic due
> > to BUG
On Mon, Oct 16, 2017 at 11:53:08AM +0300, Nikolay Borisov wrote:
>
>
> On 13.10.2017 23:51, Liu Bo wrote:
> > On Wed, Oct 11, 2017 at 10:38:50AM +0300, Nikolay Borisov wrote:
> >>
> >>
> >> On 10.10.2017 20:53, Liu Bo wrote:
> >>> We've
On Mon, Oct 30, 2017 at 11:14:38AM -0600, Liu Bo wrote:
> If a file's DIR_ITEM key is invalid (due to memory errors) and gets
> written to disk, a future lookup_path can end up with kernel panic due
> to BUG_ON().
>
> This gets rid of the BUG_ON(), meanwhile output the corrup
s is typically 256. And all fields for
limiting max_active are removed, including current_active,
limit_active, thresh etc.
Signed-off-by: Liu Bo
---
fs/btrfs/async-thread.c | 155 +++
fs/btrfs/async-thread.h | 27 +++--
fs/btrfs/delayed
201 - 300 of 2564 matches
Mail list logo