Wilson, Ellis posted on Fri, 05 Oct 2018 15:29:52 + as excerpted:
> Is there any tuning in BTRFS that limits the number of outstanding reads
> at a time to a small single-digit number, or something else that could
> be behind small queue depths? I can't otherwise imagine what the
>
On 10/05/2018 04:42 PM, Nikolay Borisov wrote:
>
>
> On 5.10.2018 00:24, Hans van Kranenburg wrote:
>> Instead of hardcoding exceptions for RAID5 and RAID6 in the code, use an
>> nparity field in raid_attr.
>>
>> Signed-off-by: Hans van Kranenburg
>> ---
>> fs/btrfs/volumes.c | 18
Filipe Manana - 05.10.18, 17:21:
> On Fri, Oct 5, 2018 at 3:23 PM Martin Steigerwald
wrote:
> > Hello!
> >
> > On ThinkPad T520 after battery was discharged and machine just
> > blacked out.
> >
> > Is that some sign of regular consistency check / replay or something
> > to investigate
On Fri, Oct 05, 2018 at 05:22:40PM +0800, Qu Wenruo wrote:
>
>
> On 2018/10/5 下午4:56, Nikolay Borisov wrote:
> >
> >
> > On 5.10.2018 11:25, Qu Wenruo wrote:
> >> Enhance btrfs_verify_dev_extents() to remember previous checked dev
> >> extents, so it can check if one dev extent overlaps with
On 10/05/2018 06:40 AM, Duncan wrote:
> Wilson, Ellis posted on Thu, 04 Oct 2018 21:33:29 + as excerpted:
>
>> Hi all,
>>
>> I'm attempting to understand a roughly 30% degradation in BTRFS RAID0
>> for large read I/Os across six disks compared with ext4 atop mdadm
>> RAID0.
>>
>>
On Fri, Oct 5, 2018 at 3:23 PM Martin Steigerwald wrote:
>
> Hello!
>
> On ThinkPad T520 after battery was discharged and machine just blacked
> out.
>
> Is that some sign of regular consistency check / replay or something to
> investigate further?
I think it's harmless, if anything were messed
On 5.10.2018 00:24, Hans van Kranenburg wrote:
> Instead of hardcoding exceptions for RAID5 and RAID6 in the code, use an
> nparity field in raid_attr.
>
> Signed-off-by: Hans van Kranenburg
> ---
> fs/btrfs/volumes.c | 18 +++---
> fs/btrfs/volumes.h | 2 ++
> 2 files changed,
Hello!
On ThinkPad T520 after battery was discharged and machine just blacked
out.
Is that some sign of regular consistency check / replay or something to
investigate further?
I already scrubbed all data and there are no errors. Also btrfs device stats
reports no errors. SMART status appears to
On 5.10.2018 15:26, Goldwyn Rodrigues wrote:
> Code cleanup.
>
> Signed-off-by: Goldwyn Rodrigues
Reviewed-by: Nikolay Borisov
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index e7f702761cb7..f7b8b7a6b86a 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -1661,14
Code cleanup.
Signed-off-by: Goldwyn Rodrigues
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index e7f702761cb7..f7b8b7a6b86a 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1661,14 +1661,10 @@ static struct dentry *btrfs_mount(struct
file_system_type *fs_type, int flags,
{
On 10/05/2018 09:51 AM, Qu Wenruo wrote:
>
>
> On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
>> This patch set contains an additional fix for a newly exposed bug after
>> the previous attempt to fix a chunk allocator bug for new DUP chunks:
>>
>>
Wilson, Ellis posted on Thu, 04 Oct 2018 21:33:29 + as excerpted:
> Hi all,
>
> I'm attempting to understand a roughly 30% degradation in BTRFS RAID0
> for large read I/Os across six disks compared with ext4 atop mdadm
> RAID0.
>
> Specifically, I achieve performance parity with BTRFS in
David Goodwin posted on Thu, 04 Oct 2018 17:44:46 +0100 as excerpted:
> While trying to run/use bedup ( https://github.com/g2p/bedup ) I
> hit this :
>
>
> [Thu Oct 4 15:34:51 2018] [ cut here ]
> [Thu Oct 4 15:34:51 2018] BTRFS: Transaction aborted (error -28)
>
Enhance btrfs_verify_dev_extents() to remember previous checked dev
extents, so it can verify no dev extents can overlap.
Link: https://www.spinics.net/lists/linux-btrfs/msg82370.html
Reported-by: Hans van Kranenburg
Signed-off-by: Qu Wenruo
---
fs/btrfs/volumes.c | 14 ++
1 file
Inspired by Hans' possible flawed DUP chunk allocator, add the following
dev extents checker:
1) Dev extent overlap check
Dev extents don't use extent_cache so it can't report dev extents
overlap.
So manually check dev extents overlap.
This check is pretty simple since we're already
Add extra dev extent end check against device boundary.
Signed-off-by: Qu Wenruo
---
fs/btrfs/volumes.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index bf0b2c16847a..bc3ac4715694 100644
--- a/fs/btrfs/volumes.c
+++
On 2018/10/5 下午4:56, Nikolay Borisov wrote:
>
>
> On 5.10.2018 11:25, Qu Wenruo wrote:
>> Enhance btrfs_verify_dev_extents() to remember previous checked dev
>> extents, so it can check if one dev extent overlaps with previous dev extent.
>>
>> Reported-by: Hans van Kranenburg
>>
Beat Meier posted on Wed, 03 Oct 2018 16:20:14 -0300 as excerpted:
> Hello
>
> I'm using btrfs on opensuse leap 42.2.
>
> This days I had a power loss and system does not mount anymore root
> filesystem with subvolumes.
>
> My original problem in dmesg was skinny extents and space cache
>
On 2018/10/5 下午4:55, Nikolay Borisov wrote:
>
>
> On 5.10.2018 11:25, Qu Wenruo wrote:
>> Add extra dev extent end check against device boundary.
>>
>> Signed-off-by: Qu Wenruo
>> ---
>> fs/btrfs/volumes.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git
On 5.10.2018 00:24, Hans van Kranenburg wrote:
> RAID5 and RAID6 profile store one copy of the data, not 2 or 3. These
> values are not used anywhere by the way.
>
> Signed-off-by: Hans van Kranenburg
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/volumes.c | 4 ++--
> 1 file changed, 2
On 5.10.2018 00:24, Hans van Kranenburg wrote:
> num_bytes is really a way too generic name for a variable in this
> function. There are a dozen other variables that hold a number of bytes
> as value.
>
> Give it a name that actually describes what it does, which is holding
> the size of the
On 5.10.2018 11:59, Nikolay Borisov wrote:
>
>
> On 5.10.2018 00:24, Hans van Kranenburg wrote:
>> num_bytes is used to store the chunk length of the chunk that we're
>> allocating. Do not reuse it for something really different in the same
>> function.
>>
>> Signed-off-by: Hans van
On 5.10.2018 00:24, Hans van Kranenburg wrote:
> num_bytes is used to store the chunk length of the chunk that we're
> allocating. Do not reuse it for something really different in the same
> function.
>
> Signed-off-by: Hans van Kranenburg
nit: That's a minor cleanup and brings no
I do observer btrfs/011 taking longer time to complete (200sec more) and
Null pointer dereference even without this patch set,
tracing back lead
to conclusion, that
Ah. My trace back was for the circular lock dependency warning which I
reported here: Subject: btrfs/011 possible
On 5.10.2018 11:25, Qu Wenruo wrote:
> Enhance btrfs_verify_dev_extents() to remember previous checked dev
> extents, so it can check if one dev extent overlaps with previous dev extent.
>
> Reported-by: Hans van Kranenburg
> Signed-off-by: Qu Wenruo
If this is related to the initial
On 5.10.2018 11:25, Qu Wenruo wrote:
> Add extra dev extent end check against device boundary.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/volumes.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index
On 5.10.2018 00:33, Wilson, Ellis wrote:
> Hi all,
>
> I'm attempting to understand a roughly 30% degradation in BTRFS RAID0
> for large read I/Os across six disks compared with ext4 atop mdadm RAID0.
>
> Specifically, I achieve performance parity with BTRFS in terms of
> single-threaded
Add extra dev extent end check against device boundary.
Signed-off-by: Qu Wenruo
---
fs/btrfs/volumes.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index bf0b2c16847a..9fb40e30be6a 100644
--- a/fs/btrfs/volumes.c
+++
Enhance btrfs_verify_dev_extents() to remember previous checked dev
extents, so it can check if one dev extent overlaps with previous dev extent.
Reported-by: Hans van Kranenburg
Signed-off-by: Qu Wenruo
---
fs/btrfs/volumes.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
Inspired by Hans' possible flawed DUP chunk allocator, add the following
dev extents checker:
1) Dev extent overlap check
Dev extents don't use extent_cache so it can't report dev extents
overlap.
So manually check dev extents overlap.
This check is pretty simple since we're already
On Sun, Sep 30, 2018 at 2:40 AM Anand Jain wrote:
>
> Try to punch hole with unaligned size and offset when the FS is
> full. Mainly holes are punched at locations which are unaligned
> with the file extent boundaries when the FS is full by data.
> As the punching holes at unaligned location will
On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
> This patch set contains an additional fix for a newly exposed bug after
> the previous attempt to fix a chunk allocator bug for new DUP chunks:
>
>
On 2018/10/5 上午5:24, Hans van Kranenburg wrote:
> This patch set contains an additional fix for a newly exposed bug after
> the previous attempt to fix a chunk allocator bug for new DUP chunks:
>
>
33 matches
Mail list logo
