waxhead posted on Fri, 22 Jun 2018 01:13:31 +0200 as excerpted:
> According to this:
>
> https://stratis-storage.github.io/StratisSoftwareDesign.pdf Page 4 ,
> section 1.2
>
> It claims that BTRFS still have significant technical issues that may
> never be resolved.
> Could someone shed some
On 06/22/2018 06:48 PM, David Sterba wrote:
On Fri, Jun 22, 2018 at 10:58:16AM +0800, Chengguang Xu wrote:
Currently, when encoutering -ERANGE in btrfs_get_acl(),
just set acl to NULL so that we cannot get proper
acl information but the operation looks successful.
Do you have a reproducer for
On 2018年06月23日 05:20, Daniel Underwood wrote:
> Thanks for the help, I started `check --repair --init-extent-tree`
> right around a week ago as a last effort before restoring from backup.
> Unfortunately, that command is still running. It does seem to be using
> about half of the system's RAM (8
On 20 Jun 2018, at 16:24, David Sterba wrote:
On Wed, Jun 20, 2018 at 03:48:08PM -0400, Chris Mason wrote:
generic/095 [18:07:03][ 3769.317862] run fstests generic/095 at
2018-06-20 18:07:03
Hmpf, I pass both 095 and 208 here.
[ 3774.849685] BTRFS: device fsid
Thanks for the help, I started `check --repair --init-extent-tree`
right around a week ago as a last effort before restoring from backup.
Unfortunately, that command is still running. It does seem to be using
about half of the system's RAM (8 of 16GB) and 100% load on a single
core. Is this type
On Fri, Jun 22, 2018 at 12:32 PM Hans van Kranenburg
wrote:
>
> On 06/22/2018 06:25 PM, Nikolay Borisov wrote:
> >
> >
> > On 22.06.2018 19:17, Su Yue wrote:
> >>
> >>
> >>
> >>> Sent: Friday, June 22, 2018 at 11:26 PM
> >>> From: "Hans van Kranenburg"
> >>> To: "Nikolay Borisov" , "Su Yue"
>
On 06/22/2018 06:25 PM, Nikolay Borisov wrote:
>
>
> On 22.06.2018 19:17, Su Yue wrote:
>>
>>
>>
>>> Sent: Friday, June 22, 2018 at 11:26 PM
>>> From: "Hans van Kranenburg"
>>> To: "Nikolay Borisov" , "Su Yue"
>>> , linux-btrfs@vger.kernel.org
>>> Subject: Re: [PATCH] btrfs: Add more details
On 22.06.2018 19:17, Su Yue wrote:
>
>
>
>> Sent: Friday, June 22, 2018 at 11:26 PM
>> From: "Hans van Kranenburg"
>> To: "Nikolay Borisov" , "Su Yue"
>> , linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH] btrfs: Add more details while checking tree block
>>
>> On 06/22/2018 01:48 PM,
> Sent: Friday, June 22, 2018 at 11:26 PM
> From: "Hans van Kranenburg"
> To: "Nikolay Borisov" , "Su Yue"
> , linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs: Add more details while checking tree block
>
> On 06/22/2018 01:48 PM, Nikolay Borisov wrote:
> >
> >
> > On 22.06.2018
> Sent: Friday, June 22, 2018 at 11:40 PM
> From: "Hugo Mills"
> To: "Hans van Kranenburg"
> Cc: "Nikolay Borisov" , "Su Yue"
> , linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs: Add more details while checking tree block
>
> On Fri, Jun 22, 2018 at 05:26:02PM +0200, Hans van
On Fri, Jun 22, 2018 at 05:26:02PM +0200, Hans van Kranenburg wrote:
> On 06/22/2018 01:48 PM, Nikolay Borisov wrote:
> >
> >
> > On 22.06.2018 04:52, Su Yue wrote:
> >> For easier debug, print eb->start if level is invalid.
> >> Also make print clear if bytenr found is not expected.
> >>
> >>
On 06/22/2018 01:48 PM, Nikolay Borisov wrote:
>
>
> On 22.06.2018 04:52, Su Yue wrote:
>> For easier debug, print eb->start if level is invalid.
>> Also make print clear if bytenr found is not expected.
>>
>> Signed-off-by: Su Yue
>> ---
>> fs/btrfs/disk-io.c | 8
>> 1 file changed,
> From: Nikolay Borisov
> Date: Fri, Jun 22, 2018 at 7:49 PM
> Subject: Re: [PATCH] btrfs: Add more details while checking tree block
> To: Su Yue ,
>
>
>
>
> On 22.06.2018 04:52, Su Yue wrote:
> > For easier debug, print eb->start if level is invalid.
> > Also make print clear if bytenr
On 22.06.2018 04:52, Su Yue wrote:
> For easier debug, print eb->start if level is invalid.
> Also make print clear if bytenr found is not expected.
>
> Signed-off-by: Su Yue
> ---
> fs/btrfs/disk-io.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
On Fri, Jun 22, 2018 at 09:52:15AM +0800, Su Yue wrote:
> For easier debug, print eb->start if level is invalid.
> Also make print clear if bytenr found is not expected.
>
> Signed-off-by: Su Yue
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Jun 21, 2018 at 10:48:27AM +0300, Nikolay Borisov wrote:
>
>
> On 20.06.2018 20:51, David Sterba wrote:
> > 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
On 2018年06月22日 17:52, David Sterba wrote:
> On Fri, Jun 22, 2018 at 12:35:00PM +0800, 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
On Fri, Jun 22, 2018 at 10:58:16AM +0800, Chengguang Xu wrote:
> Currently, when encoutering -ERANGE in btrfs_get_acl(),
> just set acl to NULL so that we cannot get proper
> acl information but the operation looks successful.
Do you have a reproducer for that?
ERANGE is returned from
On Fri, Jun 22, 2018 at 12:35:00PM +0800, 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):
On Fri, Jun 22, 2018 at 04:18:01PM +0800, Su Yue wrote:
> If type of extent_inline_ref found is not expected, filesystem may have
> been corrupted, should return EUCLEAN instead of EINVAL.
> No functional changes.
>
> Signed-off-by: Su Yue
> ---
> Changelog:
> v2:
> Add changes in
On Fri, Jun 22, 2018 at 5: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
If type of extent_inline_ref found is not expected, filesystem may have
been corrupted, should return EUCLEAN instead of EINVAL.
No functional changes.
Signed-off-by: Su Yue
---
Changelog:
v2:
Add changes in build_backref_tree, get_extent_inline_ref and
add_inline_refs.
On 2018年06月22日 15:42, cgxu519 wrote:
> On 06/22/2018 01:59 PM, Qu Wenruo wrote:
>>
>> On 2018年06月22日 10:58, Chengguang Xu wrote:
>>> Currently, when encoutering -ERANGE in btrfs_get_acl(),
>>> just set acl to NULL so that we cannot get proper
>>> acl information but the operation looks
On 22.06.2018 10:53, Su Yue wrote:
> If type of extent_inline_ref found is not expected, filesystem may have
> been corrupted, should return EUCLEAN instead of EINVAL.
> No functional changes.
>
> Signed-off-by: Su Yue
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/extent-tree.c | 2 +-
>
If type of extent_inline_ref found is not expected, filesystem may have
been corrupted, should return EUCLEAN instead of EINVAL.
No functional changes.
Signed-off-by: Su Yue
---
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/relocation.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
On 06/22/2018 01:59 PM, Qu Wenruo wrote:
On 2018年06月22日 10:58, Chengguang Xu wrote:
Currently, when encoutering -ERANGE in btrfs_get_acl(),
just set acl to NULL so that we cannot get proper
acl information but the operation looks successful.
This patch treats -ERANGE as an error case and
On 2018年06月22日 10:58, Chengguang Xu wrote:
> Currently, when encoutering -ERANGE in btrfs_get_acl(),
> just set acl to NULL so that we cannot get proper
> acl information but the operation looks successful.
>
> This patch treats -ERANGE as an error case and meanwhile
> print real errno before
27 matches
Mail list logo
