Alright, I have rebuilt kernel 4.14.8 and added the line of code you
gave me. The kernel is installed and I have a full balance running.
Right off the bat one thing I noticed is that the last time I ran a
full balance, balance status showed something like "14 out of about
200 chunks balanced". I th
On 2017年12月21日 15:09, Su Yue wrote:
>
>
> On 12/21/2017 02:51 PM, Qu Wenruo wrote:
>>
>>
>> On 2017年12月20日 16:37, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年12月20日 16:21, Su Yue wrote:
On 12/20/2017 01:41 PM, Qu Wenruo wrote:
>
>
> On 2017年12月20日 12:57, Su Yue wrote:
>>
On 12/21/2017 02:51 PM, Qu Wenruo wrote:
On 2017年12月20日 16:37, Qu Wenruo wrote:
On 2017年12月20日 16:21, Su Yue wrote:
On 12/20/2017 01:41 PM, Qu Wenruo wrote:
On 2017年12月20日 12:57, Su Yue wrote:
Introduce create_chunk_and_block_block_group() to allocate new chunk
and corresponding blo
On 12/21/2017 02:51 PM, Qu Wenruo wrote:
On 2017年12月20日 16:37, Qu Wenruo wrote:
On 2017年12月20日 16:21, Su Yue wrote:
On 12/20/2017 01:41 PM, Qu Wenruo wrote:
On 2017年12月20日 12:57, Su Yue wrote:
Introduce create_chunk_and_block_block_group() to allocate new chunk
and corresponding blo
On 2017年12月20日 16:37, Qu Wenruo wrote:
>
>
> On 2017年12月20日 16:21, Su Yue wrote:
>>
>>
>> On 12/20/2017 01:41 PM, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年12月20日 12:57, Su Yue wrote:
Introduce create_chunk_and_block_block_group() to allocate new chunk
and corresponding block group.
>
Holger Hoffstätte posted on Wed, 20 Dec 2017 20:58:14 +0100 as excerpted:
> On 12/20/17 20:02, Chris Murphy wrote:
>> I don't know if it's the sending MUA or the list server, but the line
>> wrapping makes this much harder to follow. I suggest putting it in a
>> text file and attaching the text fi
Hi tejun
On 12/16/2017 08:07 PM, Tejun Heo wrote:
> After the recent updates to use generation number and state based
> synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE except
> to avoid firing the same timeout multiple times.
>
> Remove all REQ_ATOM_COMPLETE usages and use a new rq
On Wed, Dec 20, 2017 at 1:14 PM, Austin S. Hemmelgarn
wrote:
> On 2017-12-20 15:07, Chris Murphy wrote:
>> There is an irony here:
>>
>> YaST doesn't have Btrfs raid1 or raid10 options; and also won't do
>> encrypted root with Btrfs either because YaST enforces LVM to do LUKS
>> encryption for so
Yeah I had a hunch that it was something to do with the 2TB disks.
I've been slowly trying to replace them. But they're the remnants of
my old storage system so it has been slow going. When I get some time
I will try and compile the kernel with your patch. Thanks!
On Wed, Dec 20, 2017 at 12:20 AM,
I switched to the LT kernel because of this issue. I was running
mainline and thought that LT would get me stability. I can switch
back to LT while we RCA.
At the risk of changing two things, I could add that
(scsi_mod.use_blk_mq=n) to my boot and also switch back to ML. I do
notice that disk I
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 1048576 (256 blocks of 4096 bytes)
ext: logical_offset:physical_offset: l
On 20.12.2017 21:16, David Ahern wrote:
> I am still seeing this problem on 4.15.0-rc3
This is a known problem and the offending commit is this one
ce8ea7cc6eb3 ("btrfs: don't call btrfs_start_delalloc_roots in
flushoncommit") and this manifests only if you have mounted with
flushoncommit mount
On 2017-12-20 15:07, Chris Murphy wrote:
On Wed, Dec 20, 2017 at 1:02 PM, Chris Murphy wrote:
On Wed, Dec 20, 2017 at 9:53 AM, Andrei Borzenkov wrote:
19.12.2017 22:47, Chris Murphy пишет:
BTW, doesn't SuSE use btrfs by default? Would you expect everyone using
this distro to research ever
On Wed, Dec 20, 2017 at 1:02 PM, Chris Murphy wrote:
> On Wed, Dec 20, 2017 at 9:53 AM, Andrei Borzenkov wrote:
>> 19.12.2017 22:47, Chris Murphy пишет:
>>>
BTW, doesn't SuSE use btrfs by default? Would you expect everyone using
this distro to research every component used?
>>>
>>>
On Wed, Dec 20, 2017 at 9:53 AM, Andrei Borzenkov wrote:
> 19.12.2017 22:47, Chris Murphy пишет:
>>
>>>
>>> BTW, doesn't SuSE use btrfs by default? Would you expect everyone using
>>> this distro to research every component used?
>>
>> As far as I'm aware, only Btrfs single device stuff is "suppor
On 12/20/17 20:02, Chris Murphy wrote:
> I don't know if it's the sending MUA or the list server, but the line
> wrapping makes this much harder to follow. I suggest putting it in a
> text file and attaching the text file. It's definitely not on the
> receiving side, I see it here also:
> https://w
On Wed, Dec 20, 2017 at 1:34 AM, Tomasz Pala wrote:
> On Tue, Dec 19, 2017 at 16:59:39 -0700, Chris Murphy wrote:
>
>>> Sth like this? I got such problem a few months ago, my solution was
>>> accepted upstream:
>>> https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
I am still seeing this problem on 4.15.0-rc3
On 11/17/17 12:55 PM, David Ahern wrote:
> I see a backtrace booting 4.14+ on a mellanox switch. The trace is due
> to the WARN_ON in __writeback_inodes_sb_nr.
>
> [ 40.958590] WARNING: CPU: 0 PID: 183 at
> /home/dsa/kernel-2.git/fs/fs-writeback.c:2
I don't know if it's the sending MUA or the list server, but the line
wrapping makes this much harder to follow. I suggest putting it in a
text file and attaching the text file. It's definitely not on the
receiving side, I see it here also:
https://www.spinics.net/lists/linux-btrfs/msg72872.html
A
On 12/20/17 3:00 AM, Masami Hiramatsu wrote:
On Fri, 15 Dec 2017 14:12:52 -0500
Josef Bacik wrote:
From: Josef Bacik
Using BPF we can override kprob'ed functions and return arbitrary
values. Obviously this can be a bit unsafe, so make this feature opt-in
for functions. Simply tag a functio
Austin S. Hemmelgarn posted on Wed, 20 Dec 2017 08:33:03 -0500 as
excerpted:
>> The obvious answer is: do it via kernel command line, just like mdadm
>> does:
>> rootflags=device=/dev/sda,device=/dev/sdb
>> rootflags=device=/dev/sda,device=missing
>> rootflags=device=/dev/sda,device=/dev/sdb,degra
On 12/19/17 11:13 PM, Masami Hiramatsu wrote:
On Tue, 19 Dec 2017 18:14:17 -0800
Alexei Starovoitov wrote:
On 12/18/17 10:29 PM, Masami Hiramatsu wrote:
+#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#ifdef CONFIG_BPF_KPROBE_OVERRIDE
BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable
The recent revert left one unused label behind:
fs/btrfs/qgroup.c: In function 'qgroup_reserve':
fs/btrfs/qgroup.c:2432:1: error: label 'retry' defined but not used
[-Werror=unused-label]
Let's remove it, too.
Fixes: b283738ab0ad ("Revert "btrfs: qgroups: Retry after commit on getting
EDQUOT""
On 2017-12-20 11:53, Andrei Borzenkov wrote:
19.12.2017 22:47, Chris Murphy пишет:
BTW, doesn't SuSE use btrfs by default? Would you expect everyone using
this distro to research every component used?
As far as I'm aware, only Btrfs single device stuff is "supported".
The multiple device st
19.12.2017 22:47, Chris Murphy пишет:
>
>>
>> BTW, doesn't SuSE use btrfs by default? Would you expect everyone using
>> this distro to research every component used?
>
> As far as I'm aware, only Btrfs single device stuff is "supported".
> The multiple device stuff is definitely not supported on
On Wed 20-12-17 09:03:06, Jeff Layton wrote:
> On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > > [PATCH] SQUASH: add memory barriers around i_version accesses
> >
> > Why explicit memory barriers rather than annotating the
Ok, caught the hung tasks last night. I don't *think* this is
related, because I pretty sure this isn't happening on the same
filesystem, but I do have a loopback swap on one btrfs drive.
The hang might have occurred after the btrfs balance was finished
which is confusing. I'm adding timest
On Wed 20-12-17 08:35:05, Dave Chinner wrote:
> On Tue, Dec 19, 2017 at 01:07:09PM +0100, Jan Kara wrote:
> > On Wed 13-12-17 09:20:04, Dave Chinner wrote:
> > > On Tue, Dec 12, 2017 at 01:05:35PM -0500, Josef Bacik wrote:
> > > > On Tue, Dec 12, 2017 at 10:36:19AM +1100, Dave Chinner wrote:
> > >
On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > [PATCH] SQUASH: add memory barriers around i_version accesses
>
> Why explicit memory barriers rather than annotating the operations
> with the required semantics and getting t
On 2017-12-19 17:23, Tomasz Pala wrote:
On Tue, Dec 19, 2017 at 15:47:03 -0500, Austin S. Hemmelgarn wrote:
Sth like this? I got such problem a few months ago, my solution was
accepted upstream:
https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
Rationale is in
On 2017-12-19 18:53, Chris Murphy wrote:
On Tue, Dec 19, 2017 at 1:11 PM, Austin S. Hemmelgarn
wrote:
On 2017-12-19 12:56, Tomasz Pala wrote:
BTRFS lacks all of these - there are major functional changes in current
kernels and it reaches far beyond LTS. All the knowledge YOU have here,
on th
On 2017-12-19 16:58, Tomasz Pala wrote:
On Tue, Dec 19, 2017 at 15:11:22 -0500, Austin S. Hemmelgarn wrote:
Except the systems running on those ancient kernel versions are not
necessarily using a recent version of btrfs-progs.
Still much easier to update a userspace tools than kernel (conside
On Fri, 15 Dec 2017 14:12:52 -0500
Josef Bacik wrote:
> From: Josef Bacik
>
> Using BPF we can override kprob'ed functions and return arbitrary
> values. Obviously this can be a bit unsafe, so make this feature opt-in
> for functions. Simply tag a function with KPROBE_ERROR_INJECT_SYMBOL in
>
On 12/20/2017 08:13 AM, Masami Hiramatsu wrote:
> On Tue, 19 Dec 2017 18:14:17 -0800
> Alexei Starovoitov wrote:
[...]
>> Please make your suggestion as patches based on top of bpf-next.
>
> bpf-next seems already pick this series. Would you mean I revert it and
> write new patch?
No, please sub
On 20.12.2017 10:04, Anand Jain wrote:
> In raid configs RAID1/RAID5/RAID6 it's possible to have some devices
> missing which would render btrfs to be mounted in degraded state but
> still be operational. In those cases it's possible (albeit highly
> undesirable) that the degraded and missing par
On 20.12.2017 10:04, Anand Jain wrote:
> When the missing device reappears and joins the RAID group, and if there
> are no more missing device at the volume level, then reset the
> BTRFS_SUPER_FLAG_VOL_MOVED_ON flag.
You should rename the flag here as well. Also I believe the changelog
can be si
Errata:
On Wed, Dec 20, 2017 at 09:34:48 +0100, Tomasz Pala wrote:
> /dev/sda -> 'not ready'
> /dev/sdb -> 'not ready'
> /dev/sdc -> 'ready', triggers /dev/sda -> 'not ready' and /dev/sdb - still
> 'not ready'
> /dev/sdc -> kernel says 'ready', triggers /dev/sda - 'ready' and /dev/sdb ->
> 'rea
On 2017年12月20日 16:21, Su Yue wrote:
>
>
> On 12/20/2017 01:41 PM, Qu Wenruo wrote:
>>
>>
>> On 2017年12月20日 12:57, Su Yue wrote:
>>> Introduce create_chunk_and_block_block_group() to allocate new chunk
>>> and corresponding block group.
>>>
>>> The new function force_cow_in_new_chunk() first all
On Tue, Dec 19, 2017 at 16:59:39 -0700, Chris Murphy wrote:
>> Sth like this? I got such problem a few months ago, my solution was
>> accepted upstream:
>> https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
>
> I can't parse this commit. In particular I can't tell
On 20.12.2017 08:42, Anand Jain wrote:
> No functional change rearrange the mutex_unlock.
>
> Signed-off-by: Anand Jain
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/transaction.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/btrfs/transaction.c b/fs/btr
On 12/20/2017 01:41 PM, Qu Wenruo wrote:
On 2017年12月20日 12:57, Su Yue wrote:
Introduce create_chunk_and_block_block_group() to allocate new chunk
and corresponding block group.
The new function force_cow_in_new_chunk() first allocates new chunk
and records its start.
Then it modifies all me
In raid configs RAID1/RAID5/RAID6 it's possible to have some devices
missing which would render btrfs to be mounted in degraded state but
still be operational. In those cases it's possible (albeit highly
undesirable) that the degraded and missing parts of the filesystem are
mounted independently. W
When the missing device reappears and joins the RAID group, and if there
are no more missing device at the volume level, then reset the
BTRFS_SUPER_FLAG_VOL_MOVED_ON flag.
This patch is on top of the patch [1] in the ML.
[1] btrfs: handle dynamically reappearing missing device
Signed-off-by: Anan
On 20.12.2017 07:13, Qu Wenruo wrote:
> btrfs_qgroup_inherit structure has two members, num_ref_copies and
> num_excl_copies, to info btrfs kernel modules to inherit (copy)
> rfer/excl numbers at snapshot/subvolume creation time.
>
> Since qgroup number is already hard to maintain for multi-leve
44 matches
Mail list logo
