At 03/08/2017 02:47 PM, Adam Borowski wrote:
On Wed, Mar 08, 2017 at 10:41:17AM +0800, Qu Wenruo wrote:
This patchset will introduce a new per-chunk degradable check for
btrfs, allow above case to succeed, and it's quite small anyway.
v3:
Remove one duplicated missing device output
Use
From: Zygo Blaxell
This is a story about 4 distinct (and very old) btrfs bugs.
Commit c8b978188c ("Btrfs: Add zlib compression support") added
three data corruption bugs for inline extents (bugs #1-3).
Commit 93c82d5750 ("Btrfs: zero page past end of inline file items")
fixed bug #1: uncompres
- if (likely(blk_queue_enter(q, false) == 0)) {
+ if (likely(blk_queue_enter(q, bio_flagged(bio, BIO_NOWAIT)) ==
0)) {
ret = q->make_request_fn(q, bio);
I think that for ->make_request to not block we'd need to set
BLK_MQ_REQ_NOWAIT in blk_m
On Wed, Mar 08, 2017 at 10:41:17AM +0800, Qu Wenruo wrote:
> This patchset will introduce a new per-chunk degradable check for
> btrfs, allow above case to succeed, and it's quite small anyway.
> v3:
> Remove one duplicated missing device output
> Use the advice from Anand Jain, not to add new
08.03.2017 05:41, Qu Wenruo пишет:
> For missing device, btrfs will just refuse to mount with almost
> meaningless kernel message like:
>
> BTRFS info (device vdb6): disk space caching is enabled
> BTRFS info (device vdb6): has skinny extents
> BTRFS error (device vdb6): failed to read the syst
At 03/08/2017 01:26 PM, Andrei Borzenkov wrote:
08.03.2017 05:41, Qu Wenruo пишет:
For missing device, btrfs will just refuse to mount with almost
meaningless kernel message like:
BTRFS info (device vdb6): disk space caching is enabled
BTRFS info (device vdb6): has skinny extents
BTRFS err
Introduce a new function, btrfs_check_rw_degradable(), to check if all
chunks in btrfs is OK for degraded rw mount.
It provides the new basis for accurate btrfs mount/remount and even
runtime degraded mount check other than old one-size-fit-all method.
Signed-off-by: Qu Wenruo
Reviewed-by: Anand
For missing device, btrfs will just refuse to mount with almost
meaningless kernel message like:
BTRFS info (device vdb6): disk space caching is enabled
BTRFS info (device vdb6): has skinny extents
BTRFS error (device vdb6): failed to read the system array: -5
BTRFS error (device vdb6): open_c
As we use per-chunk degradable check, now the global
num_tolerated_disk_barrier_failures is of no use.
So cleanup it.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 2 --
fs/btrfs/disk-io.c | 54 --
fs/btrfs/disk-io.h | 2 --
fs/btrfs/vol
Now use the btrfs_check_rw_degradable() to do mount time degration check.
With this patch, now we can mount with the following case:
# mkfs.btrfs -f -m raid1 -d single /dev/sdb /dev/sdc
# wipefs -a /dev/sdc
# mount /dev/sdb /mnt/btrfs -o degraded
As the single data chunk is only in sdb, so it'
Just the same for mount time check, use btrfs_check_rw_degradable() to
check if we are OK to be remounted rw.
Signed-off-by: Qu Wenruo
---
fs/btrfs/super.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index da687dc79cce..1f5772501c9
Btrfs currently uses num_tolerated_disk_barrier_failures to do global
check for tolerated missing device.
Although the one-size-fit-all solution is quite safe, it's too strict
if data and metadata has different duplication level.
For example, if one use Single data and RAID1 metadata for 2 disks,
The last user of num_tolerated_disk_barrier_failures is
barrier_all_devices().
But it's can be easily changed to new per-chunk degradable check
framework.
Now btrfs_device will have two extra members, representing send/wait
error, set at write_dev_flush() time.
With these 2 new members, btrfs_chec
Introduce a new structure, extra_rw_degrade_errors, to record
devid<->error mapping.
This strucutre will have a array to record runtime error, which affects
degraded mount, like failure to flush or wait one device.
Also allow btrfs_check_rw_degradable() to accept such structure as
another error s
This test case will test if file system works well when handling large
write while available space are all fragmented.
This can expose a bug in a btrfs unmerged patch, which wrongly modified
the delayed allocation code, to exit before allocating all space, and
cause hang when unmounting.
The wron
[BUG]
If run_delalloc_range() returns error and there is already some ordered
extents created, btrfs will be hanged with the following backtrace:
Call Trace:
__schedule+0x2d4/0xae0
schedule+0x3d/0x90
btrfs_start_ordered_extent+0x160/0x200 [btrfs]
? wake_atomic_t_function+0x60/0x60
btrfs_run_o
[BUG]
When btrfs_reloc_clone_csum() reports error, it can underflow metadata
and leads to kernel assertion on outstanding extents in
run_delalloc_nocow() and cow_file_range().
BTRFS info (device vdb5): relocating block group 12582912 flags data
BTRFS info (device vdb5): found 1 extents
assertio
On Tue, Mar 07, 2017 at 11:34:44PM +0100, Adam Borowski wrote:
> If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs
> balance -dconvert=raid1", the meta.target field will be uninitialized.
> That's otherwise ok, as it's unused except for this warning.
>
> Thus, let's use the
At 03/08/2017 09:16 AM, Liu Bo wrote:
On Wed, Mar 08, 2017 at 12:17:16AM +, Filipe Manana wrote:
On Tue, Mar 7, 2017 at 8:59 PM, Liu Bo wrote:
On Tue, Mar 07, 2017 at 12:49:58PM -0800, Liu Bo wrote:
On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
[BUG]
When btrfs_reloc_clone
On Tue, Mar 07, 2017 at 08:41:06PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When attempting to COW a file range (we are starting writeback and doing
> COW), if we manage to reserve an extent for the range we will write into
> but fail after reserving it and before creating the
On Wed, Mar 08, 2017 at 12:17:16AM +, Filipe Manana wrote:
> On Tue, Mar 7, 2017 at 8:59 PM, Liu Bo wrote:
> > On Tue, Mar 07, 2017 at 12:49:58PM -0800, Liu Bo wrote:
> >> On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
> >> > [BUG]
> >> > When btrfs_reloc_clone_csum() reports error
Hi Zygo,
On Tue, Dec 13, 2016 at 01:40:13AM -0500, Zygo Blaxell wrote:
> On Sun, Dec 11, 2016 at 10:56:59PM +0100, Xin Zhou wrote:
> >Hi Zygo,
> >
> >Since the corruption happens after I/O and checksum,
> >could it be possible to add some bug catcher code in debug build, to help
>
On Tue, Mar 7, 2017 at 10:03 PM, Liu Bo wrote:
> On Tue, Mar 07, 2017 at 04:24:49AM +, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> When attempting to COW a file range (we are starting writeback and doing
>> COW), if we manage to reserve an extent for the range we will write into
>
On 2017/03/07 20:54, David Sterba wrote:
> On Tue, Mar 07, 2017 at 11:03:33AM +0900, Tsutomu Itoh wrote:
>> Hi David,
>>
>> On 2017/03/02 23:59, David Sterba wrote:
>>> Hi,
>>>
>>> a pre-release has been tagged. There are patches that have queued so far,
>>> but
>>> I haven't gone through everythi
At 03/08/2017 08:21 AM, Filipe Manana wrote:
On Wed, Mar 8, 2017 at 12:18 AM, Qu Wenruo wrote:
At 03/08/2017 06:11 AM, Liu Bo wrote:
On Mon, Mar 06, 2017 at 10:55:47AM +0800, Qu Wenruo wrote:
[BUG]
If run_delalloc_range() returns error and there is already some ordered
extents created,
From: Filipe Manana
When attempting to COW a file range (we are starting writeback and doing
COW), if we manage to reserve an extent for the range we will write into
but fail after reserving it and before creating the respective ordered
extent, we end up in an error path where we attempt to decre
At 03/07/2017 11:13 PM, David Sterba wrote:
On Mon, Feb 27, 2017 at 03:10:30PM +0800, Qu Wenruo wrote:
Pull request can be fetched from my github:
https://github.com/adam900710/linux.git qgroup_fixes_for_4.11
The base is 6288d6eabc7505f42dda34a2c2962f91914be3a4.
Author: Liu Bo
Date: Tue Fe
From: Filipe Manana
When attempting to COW a file range (we are starting writeback and doing
COW), if we manage to reserve an extent for the range we will write into
but fail after reserving it and before creating the respective ordered
extent, we end up in an error path where we attempt to decre
At 03/08/2017 03:21 AM, Jeff Mahoney wrote:
On 2/27/17 2:10 AM, Qu Wenruo wrote:
[BUG]
The easist way to reproduce the bug is:
--
# mkfs.btrfs -f $dev -n 16K
# mount $dev $mnt -o inode_cache
# btrfs quota enable $mnt
# btrfs quota rescan -w $mnt
# btrfs qgroup show $mnt
qgroupid
On Tue, Mar 7, 2017 at 8:59 PM, Liu Bo wrote:
> On Tue, Mar 07, 2017 at 12:49:58PM -0800, Liu Bo wrote:
>> On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
>> > [BUG]
>> > When btrfs_reloc_clone_csum() reports error, it can underflow metadata
>> > and leads to kernel assertion on outstan
On Wed, Mar 8, 2017 at 12:18 AM, Qu Wenruo wrote:
>
>
> At 03/08/2017 06:11 AM, Liu Bo wrote:
>>
>> On Mon, Mar 06, 2017 at 10:55:47AM +0800, Qu Wenruo wrote:
>>>
>>> [BUG]
>>> If run_delalloc_range() returns error and there is already some ordered
>>> extents created, btrfs will be hanged with th
At 03/08/2017 04:49 AM, Liu Bo wrote:
On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
[BUG]
When btrfs_reloc_clone_csum() reports error, it can underflow metadata
and leads to kernel assertion on outstanding extents in
run_delalloc_nocow() and cow_file_range().
BTRFS info (device
At 03/08/2017 06:11 AM, Liu Bo wrote:
On Mon, Mar 06, 2017 at 10:55:47AM +0800, Qu Wenruo wrote:
[BUG]
If run_delalloc_range() returns error and there is already some ordered
extents created, btrfs will be hanged with the following backtrace:
Call Trace:
__schedule+0x2d4/0xae0
schedule+0x3d
On Mon, Mar 06, 2017 at 10:55:47AM +0800, Qu Wenruo wrote:
> [BUG]
> If run_delalloc_range() returns error and there is already some ordered
> extents created, btrfs will be hanged with the following backtrace:
>
> Call Trace:
> __schedule+0x2d4/0xae0
> schedule+0x3d/0x90
> btrfs_start_ordered_
If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs
balance -dconvert=raid1", the meta.target field will be uninitialized.
That's otherwise ok, as it's unused except for this warning.
Thus, let's use the existing set of raid levels for the comparison.
As a side effect, non-c
On Tue, Mar 07, 2017 at 06:42:51AM +0100, Adam Borowski wrote:
> If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs
> balance -dconvert=raid1", the meta.target field will be uninitialized.
> That's otherwise ok, as it's unused except for this warning.
>
> Thus, let's use the
On Tue, Mar 07, 2017 at 12:49:58PM -0800, Liu Bo wrote:
> On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
> > [BUG]
> > When btrfs_reloc_clone_csum() reports error, it can underflow metadata
> > and leads to kernel assertion on outstanding extents in
> > run_delalloc_nocow() and cow_file
On Tue, Mar 07, 2017 at 06:32:23PM +0100, David Sterba wrote:
> On Mon, Mar 06, 2017 at 11:19:32PM +, Filipe Manana wrote:
> > On Mon, Mar 6, 2017 at 2:55 AM, Qu Wenruo wrote:
> > > [BUG]
> > > When btrfs_reloc_clone_csum() reports error, it can underflow metadata
> > > and leads to kernel ass
On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote:
> [BUG]
> When btrfs_reloc_clone_csum() reports error, it can underflow metadata
> and leads to kernel assertion on outstanding extents in
> run_delalloc_nocow() and cow_file_range().
>
> BTRFS info (device vdb5): relocating block group 1
On Mon, Mar 06, 2017 at 11:19:32PM +, Filipe Manana wrote:
> On Mon, Mar 6, 2017 at 2:55 AM, Qu Wenruo wrote:
> > [BUG]
> > When btrfs_reloc_clone_csum() reports error, it can underflow metadata
> > and leads to kernel assertion on outstanding extents in
> > run_delalloc_nocow() and cow_file_r
On Mon, Mar 06, 2017 at 09:41:51AM -0800, Omar Sandoval wrote:
> On Sat, Mar 04, 2017 at 12:32:50PM -0600, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > Code cleanup.
> > The code block is for !(*flags & MS_RDONLY). We don't need
> > to check it again.
>
> Reviewed-by: Omar Sandov
Am 07.03.2017 um 15:12 schrieb Hans van Kranenburg:
On 03/05/2017 11:50 PM, Lukas Tribus wrote:
I upgraded btrfs-tools to 4.8.1 as 4.4 didn't have btrfs
inspect-internal dump-tree.
But I cannot find anything about 5242107641856 in the dump-tree output.
What does that mean?
I have no idea. It
On Tue, Mar 07, 2017 at 01:54:31PM +0800, Qu Wenruo wrote:
>
>
> At 03/07/2017 10:20 AM, Liu Bo wrote:
> > The bug is a regression after commit
> > (da2c7009f6ca "btrfs: teach __process_pages_contig about PAGE_LOCK
> > operation")
> > and commit
> > (76c0021db8fd "Btrfs: use helper to simplify l
On Tue, Mar 07, 2017 at 04:48:24PM +0100, David Sterba wrote:
> On Fri, Mar 03, 2017 at 06:41:27PM -0800, Liu Bo wrote:
> > + TP_printk_btrfs(
> > + "root %llu(%s) ino %llu sz 0x%llx disk_isz 0x%llx "
> > + "file extent range [0x%llx 0x%llx] "
> > + "(num_bytes 0x%ll
On 2/27/17 2:10 AM, Qu Wenruo wrote:
> [BUG]
> The easist way to reproduce the bug is:
> --
> # mkfs.btrfs -f $dev -n 16K
> # mount $dev $mnt -o inode_cache
> # btrfs quota enable $mnt
> # btrfs quota rescan -w $mnt
> # btrfs qgroup show $mnt
> qgroupid rfer excl
>
On 2/27/17 2:10 AM, Qu Wenruo wrote:
> Newly introduced qgroup reserved space trace points are normally nested
> into several common qgroup operations.
>
> While some other trace points are not well placed to co-operate with
> them, causing confusing output.
>
> This patch re-arrange trace_btrfs_
From: Filipe Manana
When attempting to COW a file range (we are starting writeback and doing
COW), if we manage to reserve an extent for the range we will write into
but fail after reserving it and before creating the respective ordered
extent, we end up in an error path where we attempt to decre
On Tue, Mar 7, 2017 at 4:05 PM, David Sterba wrote:
> On Mon, Mar 06, 2017 at 11:32:47PM +, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> The delalloc_end parameter for extent_clear_unlock_delalloc() is never
>> used, and only making the code for all callers longer and more complex.
On 2/27/17 2:10 AM, Qu Wenruo wrote:
> Introduce the following trace points:
> qgroup_update_reserve
> qgroup_meta_reserve
>
> These trace points are handy to trace qgroup reserve space related
> problems.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/qgroup.c| 15 +++
>
Hi, I know that raid5/6 is experimental. I have a volume that I can
mount read-only but not read-write that is stuck in a replace. I've
put a bunch of info into this pastebin: http://pastebin.com/1SQuRGet
Since then I have updated to kernel 4.10.1 and btrfs-progs to 4.9.1,
same issue. It seems tha
On Mon, Mar 06, 2017 at 11:32:47PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The delalloc_end parameter for extent_clear_unlock_delalloc() is never
> used, and only making the code for all callers longer and more complex.
> Just remove it.
It's been added on purpose
https://gi
On Fri, Mar 03, 2017 at 06:41:27PM -0800, Liu Bo wrote:
> + TP_printk_btrfs(
> + "root %llu(%s) ino %llu sz 0x%llx disk_isz 0x%llx "
> + "file extent range [0x%llx 0x%llx] "
> + "(num_bytes 0x%llx ram_bytes 0x%llx disk_bytenr 0x%llx "
> + "disk_nu
On Mon, Feb 27, 2017 at 03:10:30PM +0800, Qu Wenruo wrote:
> Pull request can be fetched from my github:
> https://github.com/adam900710/linux.git qgroup_fixes_for_4.11
>
> The base is 6288d6eabc7505f42dda34a2c2962f91914be3a4.
> Author: Liu Bo
> Date: Tue Feb 21 12:12:58 2017 -0800
>
> Bt
On Mon, Feb 27, 2017 at 03:10:31PM +0800, Qu Wenruo wrote:
> +TRACE_EVENT(qgroup_update_reserve,
...
> + TP_printk_btrfs("qgid = %llu, cur_reserved = %llu, diff = %lld",
> + __entry->qgid, __entry->cur_reserved, __entry->diff)
> +);
> +
> +TRACE_EVENT(qgroup_meta_reserve,
...
> +
On Mon 06-03-17 13:22:14, Andrew Morton wrote:
> On Mon, 6 Mar 2017 14:14:05 +0100 Michal Hocko wrote:
[...]
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -210,8 +210,16 @@ struct vm_area_struct;
> > *
> > * GFP_NOIO will use direct reclaim to discard clean pages or slab
On 03/05/2017 11:50 PM, Lukas Tribus wrote:
>
> Am 24.02.2017 um 01:26 schrieb Hans van Kranenburg:
>>
>>> Once that is done, I would like to go over the "btrfs recovery" thread
>>> and see if it can
>>> be applied for my case as well. I will certainly need your help when
>>> that time comes...
>>
On Sat, Mar 04, 2017 at 12:33:22PM -0600, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> The problem is with parallel mounting multiple subvolumes rw when the
> root filesystem is marked as read-only such as a boot sequence
> using systemd. Not all subvolumes will be mounted because some
Hi,
I want to know if re-mounting the root filesystem read-only should
change subvolumes mounted as read-write to read-only as well? We do
allow mounting subvolumes RW _after_ the root filesystem is mounted RO.
# mount /dev/vdb /mnt
# mount -o ro,subvol=svro /dev/vdb /mnt/svro
# mount -o rw,su
On Tue, Mar 07, 2017 at 11:03:33AM +0900, Tsutomu Itoh wrote:
> Hi David,
>
> On 2017/03/02 23:59, David Sterba wrote:
> > Hi,
> >
> > a pre-release has been tagged. There are patches that have queued so far,
> > but
> > I haven't gone through everything that's in the mailinglist. The 4.10
> >
On 03/06/2017 04:58 PM, Qu Wenruo wrote:
The last user of num_tolerated_disk_barrier_failures is
barrier_all_devices().
But it's can be easily changed to new per-chunk degradable check
framework.
Now btrfs_device will have two extra members, representing send/wait
error, set at write_dev_flush
On 03/06/2017 04:58 PM, Qu Wenruo wrote:
Introduce a new function, btrfs_check_rw_degradable(), to check if all
chunks in btrfs is OK for degraded rw mount.
It provides the new basis for accurate btrfs mount/remount and even
runtime degraded mount check other than old one-size-fit-all method.
At 03/07/2017 03:41 PM, Reshetova, Elena wrote:
At 03/06/2017 05:43 PM, Reshetova, Elena wrote:
At 03/03/2017 04:55 PM, Elena Reshetova wrote:
Now when new refcount_t type and API are finally merged
(see include/linux/refcount.h), the following
patches convert various refcounters in the btr
At 03/07/2017 03:08 PM, Qu Wenruo wrote:
At 03/07/2017 02:55 PM, Anand Jain wrote:
1) About reentrancy
In previous version, the err_* bits are still put into btrfs_devices
structure, just timing of resetting these bits are changes.
So either way, it's not reentrant in theory.
But that
1) About reentrancy
In previous version, the err_* bits are still put into btrfs_devices
structure, just timing of resetting these bits are changes.
So either way, it's not reentrant in theory.
But that doesn't make a problem, as we have other things to protect when
calling write_all_supers
64 matches
Mail list logo
