On 21.06.2018 05:05, Qu Wenruo wrote:
>
>
> On 2018年06月20日 20:49, Nikolay Borisov wrote:
>> It can be referenced from trans since the function is always called
>> within a transaction
>>
>> Signed-off-by: Nikolay Borisov
>> ---
>> fs/btrfs/extent-tree.c | 10 --
>> 1 file changed, 4
On 2018年06月20日 20:48, Nikolay Borisov wrote:
> Hello,
>
> This series aims at removing all the redundant btrfs_fs_info args being
> passed to functions in extent-tree.c. Each patch removes the arg from a
> one function hence it should be fairly easy to review each one of those
> patches.
On 2018年06月20日 20:49, Nikolay Borisov wrote:
> It can be referenced from trans since the function is always called
> within a transaction
>
> Signed-off-by: Nikolay Borisov
> ---
> fs/btrfs/extent-tree.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git
Chris Mason writes:
> On 19 Jun 2018, at 23:51, Huang, Ying wrote:
"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 of
On Thu, Jun 21, 2018 at 05:16:06AM +0800, kbuild test robot wrote:
> Hi Bart,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on v4.18-rc1]
> [also build test ERROR on next-20180620]
> [cannot apply to btrfs/next]
> [if your patch is appli
Hi Bart,
I love your patch! Yet something to improve:
[auto build test ERROR on v4.18-rc1]
[also build test ERROR on next-20180620]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Wed, Jun 20, 2018 at 03:48:08PM -0400, Chris Mason wrote:
>
>
> On 20 Jun 2018, at 15:33, David Sterba wrote:
>
> > On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote:
> >> We've been hunting the root cause of data crc errors here at FB for a
> >> while.
> >> We'd find one or two
On 20 Jun 2018, at 15:33, David Sterba wrote:
On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote:
We've been hunting the root cause of data crc errors here at FB for a
while.
We'd find one or two corrupted files, usually displaying crc errors
without any
corresponding IO errors
On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote:
> We've been hunting the root cause of data crc errors here at FB for a while.
> We'd find one or two corrupted files, usually displaying crc errors without
> any
> corresponding IO errors from the storage. The bug was rare enough that
On Wed, 2018-06-20 at 13:19 -0400, Jeff Mahoney wrote:
> The shed should be yellow.
>
> -Jeff
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 891cd2ed5dd4..57c9da0b459f 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -2375,21 +2375,20 @@ static __cold void
Prepartory work to fix race between mount and device scan.
The callers will have to manage the critical section, eg. mount wants
to scan and then call btrfs_open_devices without the ioctl scan walking
in and modifying the fs devices in the meantime.
Signed-off-by: David Sterba
---
In preparation to take a big lock, move resource initialization before
the critical section. It's not obvious from the diff, the desired order
is:
- initialize mount security options
- allocate temporary fs_info
- allocate superblock buffers
Signed-off-by: David Sterba
---
fs/btrfs/super.c |
Technically this extends the critical section covered by uuid_mutex to:
- parse early mount options -- here we can call device scan on paths
that can be passed as 'device=/dev/...'
- scan the device passed to mount
- open the devices related to the fs_devices -- this increases
Prepartory work to fix race between mount and device scan.
The callers will have to manage the critical section, eg. mount wants to
scan and then call btrfs_open_devices without the ioctl scan walking in
and modifying the fs devices in the meantime.
Signed-off-by: David Sterba
---
Commit 542c5908abfe84f7b4c1 ("btrfs: replace uuid_mutex by
device_list_mutex in btrfs_open_devices") switched to device_list_mutex
as we need that for the device list traversal, but we also need
uuid_mutex to protect access to fs_devices::opened to be consistent with
other users of that item.
CC:
Prepartory work to fix race between mount and device scan.
btrfs_parse_early_options calls the device scan from mount and we'll
need to let mount completely manage the critical section.
Signed-off-by: David Sterba
---
fs/btrfs/super.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
The stale device list removal needs to be protected by device_list_mutex
too as this could delete from the list and could race with another list
modification and cause crash.
The device needs to be fully initialized before it's added to the list
so the fs_devices also need to be set under the
This patchset fixes the bugs recently reported by syzbot. I've tried to
use patches from Anand [1] to fix that but in the end there were fixes
not suitable for merging to 4.18 and my final fix took a different
approach.
In short, fs_devices::opened is protected by uuid_mutex and this mutex
can be
On 6/20/18 12:55 PM, David Sterba wrote:
> On Wed, Jun 20, 2018 at 04:44:54PM +, Bart Van Assche wrote:
>> On Mon, 2018-06-18 at 12:31 +0300, Nikolay Borisov wrote:
>>> On 18.06.2018 12:26, David Sterba wrote:
On Sat, Jun 16, 2018 at 01:28:13PM +0300, Nikolay Borisov wrote:
> I'd
Hello Chris and Josef,
The three patches in this series address complaints reported by static
analyzers (gcc + W=1, sparse, smatch). These patches do not change any
functionality. Please consider these for inclusion in the upstream
kernel.
Thanks,
Bart.
Bart Van Assche (3):
btrfs: Fix
This patch avoids that the compiler complains that a fall-through
annotation is missing when building with W=1.
Signed-off-by: Bart Van Assche
---
fs/btrfs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 81107ad49f3a..3e298f26a383 100644
---
This patch avoids that building the BTRFS source code with smatch
triggers complaints about inconsistent indenting.
Signed-off-by: Bart Van Assche
---
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/ioctl.c | 4 ++--
fs/btrfs/reada.c | 2 +-
3 files changed, 5 insertions(+), 5
The C programming language does not allow to use preprocessor statements
inside macro arguments (pr_info() is defined as a macro). Hence rework
the pr_info() statement in btrfs_print_mod_info() such that it becomes
compliant. This patch allows tools like sparse to analyze the BTRFS
source code.
On Wed, Jun 20, 2018 at 04:44:54PM +, Bart Van Assche wrote:
> On Mon, 2018-06-18 at 12:31 +0300, Nikolay Borisov wrote:
> > On 18.06.2018 12:26, David Sterba wrote:
> > > On Sat, Jun 16, 2018 at 01:28:13PM +0300, Nikolay Borisov wrote:
> > > > I'd rather not see more printk being added.
On Mon, 2018-06-18 at 12:31 +0300, Nikolay Borisov wrote:
> On 18.06.2018 12:26, David Sterba wrote:
> > On Sat, Jun 16, 2018 at 01:28:13PM +0300, Nikolay Borisov wrote:
> > > I'd rather not see more printk being added. Nothing prevents from having
> > > the fmt string being passed to pr_info.
> >
We've been hunting the root cause of data crc errors here at FB for a while.
We'd find one or two corrupted files, usually displaying crc errors without any
corresponding IO errors from the storage. The bug was rare enough that we'd
need to watch a large number of machines for a few days just to
For COW, btrfs expects pages dirty pages to have been through a few setup
steps. This includes reserving space for the new block allocations and marking
the range in the state tree for delayed allocation.
A few places outside btrfs will dirty pages directly, especially when unmapping
mmap'd
During buffered writes, we follow this basic series of steps:
again:
lock all the pages
wait for writeback on all the pages
Take the extent range lock
wait for ordered extents on the whole range
clean all the pages
if (copy_from_user_in_atomic()
On Wed, May 23, 2018 at 11:22:20AM +0300, Nikolay Borisov wrote:
>
>
> On 23.05.2018 11:06, Su Yue wrote:
> > Commit 5a5003df98d5 ("btrfs: delayed-ref: double free in
> > btrfs_add_delayed_tree_ref()") fixed double free problem by creating
> > an unnessesary label to jump.
> > The elegant way is
Currently this function takes the root as an argument only to get the
log_root from it. Simplify this by directly passing the log root from
the caller. Also eliminate the fs_info local var, since it's used only
once, so directly reference it from the transaction handle.
Signed-off-by: Nikolay
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 older fs_devices, then the mount thread
> will lead to oops.
>
>
On Mon, Jun 04, 2018 at 11:00:28PM +0800, Anand Jain wrote:
> Add bitmap btrfs_fs_devices::volume_state to maintain the volume states and
> flags. This patch in perticular converts btrfs_fs_devices::rotating into
> flag BTRFS_VOLUME_STATE_ROTATING.
I'm not sure we need this. There are 2 flags, we
On Thu, May 24, 2018 at 11:49:04AM +0100, Filipe Manana wrote:
> On Wed, May 23, 2018 at 4:58 PM, Josef Bacik wrote:
> > From: Josef Bacik
> >
> > There's a priority inversion that exists currently with btrfs fsync. In
> > some cases we will collect outstanding ordered extents onto a list and
>
On Sat, May 26, 2018 at 03:48:31PM +0300, Nikolay Borisov wrote:
> > + ret = log_extent_csums(trans, inode, root, em);
>
> With the following minor diff:
>
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index daf32dc94dc3..34d5b0630824 100644
> --- a/fs/btrfs/tree-log.c
> +++
On Wed, May 23, 2018 at 11:58:33AM -0400, Josef Bacik wrote:
> From: Josef Bacik
>
> There's a priority inversion that exists currently with btrfs fsync. In
> some cases we will collect outstanding ordered extents onto a list and
> only wait on them at the very last second. However this "very
On Wed, Jun 20, 2018 at 03:11:46PM +0800, Lu Fengqi wrote:
> On Tue, Jun 19, 2018 at 03:27:54PM +0200, David Sterba wrote:
> >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
This function is always called with a valid transaction from where the
fs_info can be referenced. No functional change.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
This function is always called with a valid transaction handle from
where fs_info can be referenced. So remove the redundant argument.
No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
This function is always called with a valid transaction so there is no
need to duplicate the fs_info, we can reference it directly from the
trans handle. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
This function always uses the leaf's extent_buffer which already
contains a reference to the fs_info. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
This argument is unused. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 4bc326df472e..18fd80e2f278 100644
--- a/fs/btrfs/ctree.c
+++
This function is always called with a valid transaction handle from
where the fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
This argument is unused. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index aeef5437ec8a..0c4c093201b5 100644
---
This function is always called with a valid transaction handle so
fs_info can be referenced from there. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
This function is always called with a valid transaction handle from
where fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
fs_info can be referenced from the transaction handle, which is always
valid. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
This function is always called with a valid transaction handle from
where we can reference the fs_info. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 4 ++--
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/volumes.c | 4 ++--
3 files changed, 6 insertions(+),
It can be referenced from trans since the function is always called
within a transaction.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/volumes.c | 7 +++
fs/btrfs/volumes.h | 3 +--
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git
This function is always called with a valid transaction handle from
where the fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
This function is always called with a valid transaction handle so we
can reference the fs_info from there. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git
This function is always called with a valid transaction from where
fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
This function is always called with a valid transaction handle from
where fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/delayed-ref.c | 4 ++--
fs/btrfs/delayed-ref.h | 3 +--
fs/btrfs/extent-tree.c | 8
3 files changed, 7 insertions(+),
The argument is no longer used so remove it.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index f13b49497f67..da0c222c013d 100644
--- a/fs/btrfs/extent-tree.c
+++
This function is always called with a valid transaction handle from
where we can reference fs_info. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/volumes.c | 2 +-
3 files changed, 4 insertions(+), 5
This function is always called with a valid transaction handle from
where fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/delayed-ref.c | 4 ++--
fs/btrfs/delayed-ref.h | 3 +--
fs/btrfs/extent-tree.c | 7 +++
3 files changed, 6 insertions(+), 8
fs_info can be refenreced from the transaction handle, since it's always
valid. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index
It can always be referneced from the passed transaction handle since
it's always valid. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
It can be referenced from trans since the function is always called
within a valid transaction
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/tree-log.c| 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git
It can be referenced from the passed block group
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 196fd467cfac..d3d61e56b61a 100644
---
This function is always called with a valid transaction handle from
where fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git
It can be referenced from the passed transaction handle.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 5 ++---
fs/btrfs/relocation.c | 3 +--
fs/btrfs/volumes.c | 2 +-
4 files changed, 5 insertions(+), 8 deletions(-)
diff --git
It can be referenced from trans since the function is always called
within a transaction
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 8
fs/btrfs/volumes.c | 2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git
It can be referenced directly from the transaction handle since it's
always valid
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index
It can be referenced from the passed bg cache.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 4 ++--
fs/btrfs/relocation.c | 2 +-
fs/btrfs/scrub.c | 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ctree.h
Hello,
This series aims at removing all the redundant btrfs_fs_info args being
passed to functions in extent-tree.c. Each patch removes the arg from a
one function hence it should be fairly easy to review each one of those
patches. I'm mainly exploiting the fact that most of the time we have
It can be referenced from trans since the function is always called
within a transaction
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index
This function is always called with a valid transaction handle from
where fs_info can be referenced. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
It can be referenced from the passed transaction handle, since it'si
always valid.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index
It can be referenced from the passed transaction handle, since it's
always valid
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 08ad7572d025..b03fe240da97
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
---
fs/btrfs/extent-tree.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff
It can be referenced from the passed block group
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 57884cd72225..196fd467cfac 100644
---
On 19 Jun 2018, at 23:51, Huang, Ying wrote:
"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 of blogbench.write_score and a
+9.6% improvement
of blogbench.read_score due to
Gandalf Corvotempesta posted on Wed, 20 Jun 2018 11:15:03 +0200 as
excerpted:
> Il giorno mer 20 giu 2018 alle ore 10:34 Duncan <1i5t5.dun...@cox.net>
> ha scritto:
>> Parity-raid is certainly nice, but mandatory, especially when there's
>> already other parity solutions (both hardware and
On 2018年06月20日 17:33, Filipe Manana wrote:
> On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote:
>>
>>
>> On 2018年06月20日 17:13, Filipe Manana wrote:
>>> On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote:
[BUG]
Under certain KVM load and LTP tests, we are possible to hit the
On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote:
>
>
> On 2018年06月20日 17:13, Filipe Manana wrote:
>> On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote:
>>> [BUG]
>>> Under certain KVM load and LTP tests, we are possible to hit the
>>> following calltrace if quota is enabled:
>>> --
>>>
On 2018年06月20日 17:13, Filipe Manana wrote:
> On Fri, Jun 15, 2018 at 2:35 AM, 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
Il giorno mer 20 giu 2018 alle ore 10:34 Duncan <1i5t5.dun...@cox.net>
ha scritto:
> Parity-raid is certainly nice, but mandatory, especially when there's
> already other parity solutions (both hardware and software) available
> that btrfs can be run on top of, should a parity-raid solution be
On Fri, Jun 15, 2018 at 2:35 AM, 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
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 (and other extents
with a special block_start value). This is because it always sets the
On Wed, Jun 20, 2018 at 3:55 AM, robbieko wrote:
> 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
Austin S. Hemmelgarn posted on Tue, 19 Jun 2018 12:58:44 -0400 as
excerpted:
> That said, I would question the value of repacking chunks that are
> already more than half full. Anything above a 50% usage filter
> generally takes a long time, and has limited value in most cases (higher
> values
Commit f8f84b2dfda5 ("btrfs: index check-integrity state hash by a dev_t")
changed how btrfsic how we index device state hash.
Now we need to access device->bdev->bd_dev, while for degraded mount
it's completely possible to have device->bdev as NULL, thus it will
trigger a NULL pointer
On 20.06.2018 10:34, Gandalf Corvotempesta wrote:
> Il giorno mer 20 giu 2018 alle ore 02:06 waxhead
> ha scritto:
>> First of all: I am not a BTRFS developer, but I follow the mailing list
>> closely and I too have a particular interest in the "RAID"5/6 feature
>> which realistically is
Il giorno mer 20 giu 2018 alle ore 02:06 waxhead
ha scritto:
> First of all: I am not a BTRFS developer, but I follow the mailing list
> closely and I too have a particular interest in the "RAID"5/6 feature
> which realistically is probably about 3-4 years (if not more) in the future.
Ok.
[cut]
On Tue, Jun 19, 2018 at 03:27:54PM +0200, David Sterba wrote:
>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
Gandalf Corvotempesta posted on Tue, 19 Jun 2018 17:26:59 +0200 as
excerpted:
> Another kernel release was made.
> Any improvements in RAID56?
Btrfs feature improvements come in "btrfs time". Think long term,
multiple releases, even multiple years (5 releases per year).
In fact, btrfs
On 2018年06月20日 14:36, Qu Wenruo wrote:
> Hi Liu and David,
>
> I see mainline kernel merged commit f8f84b2dfda5 ("btrfs: index
> check-integrity state hash by a dev_t"), and you reviewed it but I can't
> find the mail in mail list, nor it's signed by David.
>
> Is this btrfs related commit
On 20.06.2018 08:34, Qu Wenruo wrote:
>
>
> 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
Hi Liu and David,
I see mainline kernel merged commit f8f84b2dfda5 ("btrfs: index
check-integrity state hash by a dev_t"), and you reviewed it but I can't
find the mail in mail list, nor it's signed by David.
Is this btrfs related commit merged without review from btrfs community?
(Well, at
89 matches
Mail list logo
