On 2018年06月20日 13:25, Nikolay Borisov wrote:
>
>
> On 15.06.2018 04:35, Qu Wenruo wrote:
>> [BUG]
>> Under certain KVM load and LTP tests, we are possible to hit the
>> following calltrace if quota is enabled:
>> --
>> BTRFS critical (device vda2): unable to find logical 8820195328 length
On 15.06.2018 04:35, Qu Wenruo wrote:
> [BUG]
> Under certain KVM load and LTP tests, we are possible to hit the
> following calltrace if quota is enabled:
> --
> BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
> BTRFS critical (device vda2): unable to find
On 20.06.2018 03:38, Qu Wenruo wrote:
> Test misc/029 only works if the test case is executed as root, while for
> sudo usage, it doesn't work as initial mkdir and final cleanup doesn't
> use $SUDO_HELPER.
>
> Add "run_check $SUDO_HELPER" for such cases to allow it works under sudo
> usage.
>
Gentle ping.
Since it's causing LTP tests failure, I'd like to backport it asap.
Thanks,
Qu
On 2018年06月15日 09:35, Qu Wenruo wrote:
> [BUG]
> Under certain KVM load and LTP tests, we are possible to hit the
> following calltrace if quota is enabled:
> --
> BTRFS critical (device vda2):
Ping * 3
"Huang, Ying" writes:
> Ping again ...
>
> "Huang, Ying" writes:
>
>> Ping...
>>
>> "Huang, Ying" writes:
>>
>>> Hi, Josef,
>>>
>>> Do you have time to take a look at the regression?
>>>
>>> kernel test robot writes:
>>>
Greeting,
FYI, we noticed a -12.3% regression
fdman...@kernel.org 於 2018-06-19 19:31 寫到:
From: Filipe Manana
Commit 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when
fm_extent_count is zero") introduced a regression where we no longer
report 0 as the physical offset for inline extents. This is because it
always sets the variable used
On 06/20/2018 10:19 AM, Chris Murphy wrote:
I've retested btrfs-progs 4.17 lowmem mode and still get a bunch of
'referencer count mismatch' that I don't see with original mode.
My bad. The bug is existed for long time since I changed lowmem mode
to traverse all trees.
Due to laziness then
I've retested btrfs-progs 4.17 lowmem mode and still get a bunch of
'referencer count mismatch' that I don't see with original mode.
e.g.
ERROR: extent[1299275636736, 2654208] referencer count mismatch (root:
2192, owner: 317900, offset: 0) wanted: 5, have: 21
Complete output attached as a text
On 06/19/2018 01:34 PM, Nikolay Borisov wrote:
On 19.06.2018 05:18, Su Yue wrote:
On 06/18/2018 07:10 PM, Nikolay Borisov wrote:
check_chunks_and_extents does quite a number of distinct things. The
first of those is going through all root items in the root tree and
classify every root
In function handle_global_options(), we reset @optind to 1.
However according to man page of getopt(3) NOTES section, if we need to
rescan options later, @optind should be reset to 0 to initialize the
internal variables correctly.
This explains the reason why in cmd_check(), getopt_long() doesn't
Test misc/029 only works if the test case is executed as root, while for
sudo usage, it doesn't work as initial mkdir and final cleanup doesn't
use $SUDO_HELPER.
Add "run_check $SUDO_HELPER" for such cases to allow it works under sudo
usage.
Signed-off-by: Qu Wenruo
---
On 06/18/2018 03:05 PM, Qu Wenruo wrote:
>
>
> On 2018年06月18日 20:02, David Sterba wrote:
>> On Mon, Jun 18, 2018 at 07:40:44PM +0800, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月18日 19:34, David Sterba wrote:
On Thu, Jun 14, 2018 at 03:17:45PM +0800, Qu Wenruo wrote:
> I understand that
On 2018年06月20日 07:18, Qu Wenruo wrote:
>
>
> On 2018年06月19日 22:47, David Sterba wrote:
>> On Mon, Jun 18, 2018 at 09:05:59PM +0800, Qu Wenruo wrote:
New code needs to be tested, documented and maintained, that's the cost
I find too high for something that's convenience for people who
Gandalf Corvotempesta wrote:
Another kernel release was made.
Any improvements in RAID56?
I didn't see any changes in that sector, is something still being
worked on or it's stuck waiting for something ?
Based on official BTRFS status page, RAID56 is the only "unstable"
item marked in red.
No
On 2018年06月19日 22:47, David Sterba wrote:
> On Mon, Jun 18, 2018 at 09:05:59PM +0800, Qu Wenruo wrote:
>>> New code needs to be tested, documented and maintained, that's the cost
>>> I find too high for something that's convenience for people who are used
>>> to some shell builtins.
>>
>> The
On 19.06.2018 22:31, Jeff Mahoney wrote:
> I like the idea here. I wasn't sold at first, but I think if we can
> standardize on taking only a trans handle when one is required and both
> a trans and fs_info when it's optional, it'll make the code clearer.
> This cleanup can percolate up the
On 6/18/18 7:59 AM, Nikolay Borisov wrote:
> This function already takes a transaction which holds a reference to
> the fs_info struct. Use that reference and remove the extra arg. No
> functional changes.
I like the idea here. I wasn't sold at first, but I think if we can
standardize on taking
On Tue, Jun 19, 2018 at 12:31:42PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
> So fix this by ensuring the physical offset is always set to 0 when we
> are processing an inline extent.
>
> Fixes: 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when fm_extent_count
> is zero")
>
On 2018-06-19 12:30, james harvey wrote:
On Tue, Jun 19, 2018 at 11:47 AM, Marc MERLIN wrote:
On Mon, Jun 18, 2018 at 06:00:55AM -0700, Marc MERLIN wrote:
So, I ran this:
gargamel:/mnt/btrfs_pool2# btrfs balance start -dusage=60 -v . &
[1] 24450
Dumping filters: flags 0x1, state 0x0, force
On Tue, Jun 19, 2018 at 11:47 AM, Marc MERLIN wrote:
> On Mon, Jun 18, 2018 at 06:00:55AM -0700, Marc MERLIN wrote:
>> So, I ran this:
>> gargamel:/mnt/btrfs_pool2# btrfs balance start -dusage=60 -v . &
>> [1] 24450
>> Dumping filters: flags 0x1, state 0x0, force is off
>> DATA (flags 0x2):
On Mon, Jun 18, 2018 at 06:00:55AM -0700, Marc MERLIN wrote:
> So, I ran this:
> gargamel:/mnt/btrfs_pool2# btrfs balance start -dusage=60 -v . &
> [1] 24450
> Dumping filters: flags 0x1, state 0x0, force is off
> DATA (flags 0x2): balancing, usage=60
> gargamel:/mnt/btrfs_pool2# while :; do
Another kernel release was made.
Any improvements in RAID56?
I didn't see any changes in that sector, is something still being
worked on or it's stuck waiting for something ?
Based on official BTRFS status page, RAID56 is the only "unstable"
item marked in red.
No interested from Suse in fixing
On Mon, Jun 18, 2018 at 09:05:59PM +0800, Qu Wenruo wrote:
> > New code needs to be tested, documented and maintained, that's the cost
> > I find too high for something that's convenience for people who are used
> > to some shell builtins.
>
> The biggest problem is, the behavior isn't even
On Thu, Jun 07, 2018 at 06:39:32PM +0200, David Sterba wrote:
> On Mon, Jun 04, 2018 at 11:00:30PM +0800, Anand Jain wrote:
> > In an instrumented testing it is possible that the mount and
> > a newer mkfs.btrfs thread on the same device can race and if the new
> > mkfs.btrfs wins it will free the
On Mon, Jun 11, 2018 at 07:24:16PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If we failed during a rename exchange operation after starting/joining a
> transaction, we would end up replacing the return value, stored in the
> local 'ret' variable, with the return value from
On Mon, Jun 18, 2018 at 02:59:23PM +0300, Nikolay Borisov wrote:
> This series improves the functions involved around extent reference
> increment.
> The first patch just removes a redundant argument, the second one documents
> the
> parameters of __btrfs_inc_extent_ref. It can be considered
On Tue, Jun 19, 2018 at 02:54:38PM +0800, Lu Fengqi wrote:
> If this condition ((BTRFS_I(src)->flags & BTRFS_INODE_NODATASUM) !=
> (BTRFS_I(dst)->flags & BTRFS_INODE_NODATASUM))
> is hit, we will go to free the uninitialized cmp.src_pages and
> cmp.dst_pages.
>
> Fixes:
On 18.06.2018 14:59, Nikolay Borisov wrote:
> This function already takes a transaction which holds a reference to
> the fs_info struct. Use that reference and remove the extra arg. No
> functional changes.
>
> Signed-off-by: Nikolay Borisov
> ---
Please ignore this patch, since I'm going
From: Filipe Manana
Commit 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when
fm_extent_count is zero") introduced a regression where we no longer
report 0 as the physical offset for inline extents. This is because it
always sets the variable used to report the physical offset ("disko")
as
If this condition ((BTRFS_I(src)->flags & BTRFS_INODE_NODATASUM) !=
(BTRFS_I(dst)->flags & BTRFS_INODE_NODATASUM))
is hit, we will go to free the uninitialized cmp.src_pages and
cmp.dst_pages.
Fixes: 67b07bd4bec5 ("Btrfs: reuse cmp workspace in EXTENT_SAME ioctl")
30 matches
Mail list logo
