I am running a single btrfs RAID10 volume of eight LUKS devices, each
using a 2TB SATA hard drive as a backing store. The SATA drives are a
mixture of Seagate and Western Digital drives, some with RPMs ranging
from 5400 to 7200. Each seems to individually performance test where I
would expect for
On 2018/06/26 1:20, David Sterba wrote:
> On Mon, Jun 25, 2018 at 01:58:58PM +0900, Misono Tomohiro wrote:
>> So, this is the updated version of
>> https://patchwork.kernel.org/patch/10063039/
>>
>> This time xfstest is ok and
>> Reviewed-by: Misono Tomohiro
>
> Your comment about
On 06-25 18:20, David Sterba wrote:
> On Mon, Jun 25, 2018 at 01:58:58PM +0900, Misono Tomohiro wrote:
> > So, this is the updated version of
> > https://patchwork.kernel.org/patch/10063039/
> >
> > This time xfstest is ok and
> > Reviewed-by: Misono Tomohiro
Yes, thats right.
>
> Your
On Mon, Jun 25, 2018 at 01:07:10PM -0400, Austin S. Hemmelgarn wrote:
> > - mount -o recovery still hung
> > - mount -o ro did not hang though
> One tip here specifically, if you had to reboot during a balance and the FS
> hangs when it mounts, try mounting with `-o skip_balance`. That should
>
On Mon, May 14, 2018 at 06:35:48PM +0200, David Sterba wrote:
> On Fri, May 11, 2018 at 01:30:01PM -0700, Omar Sandoval wrote:
> > On Fri, May 11, 2018 at 09:05:38PM +0100, Al Viro wrote:
> > > On Thu, May 10, 2018 at 11:30:10PM -0700, Omar Sandoval wrote:
> > > > do_blockdev_direct_IO(struct
On 2018-06-25 12:07, Marc MERLIN wrote:
On Tue, Jun 19, 2018 at 12:58:44PM -0400, Austin S. Hemmelgarn wrote:
In your situation, I would run "btrfs pause ", wait to hear from
a btrfs developer, and not use the volume whatsoever in the meantime.
I would say this is probably good advice. I
The vm_fault_t conversion commit introduced a ret2 variable for tracking
the integer return values from internal btrfs functions. It was
sometimes returning VM_FAULT_LOCKED for pages that were actually invalid
and had been removed from the radix. Something like this:
ret2 =
On Mon, Jun 25, 2018 at 06:43:38PM +0200, waxhead wrote:
[snip]
> I hope I am not asking for too much (but I know I probably am), but
> I suggest that having a small snippet of information on the status
> page showing a little bit about what is either currently the
> development focus , or what
On Mon, Jun 25, 2018 at 06:24:37PM +0200, Hans van Kranenburg wrote:
> >> output hasn't changed for over 36 hours, unless you've got an insanely slow
> >> storage array, that's extremely unusual (it should only be moving at most
> >> 3GB of data per chunk)).
> >
> > I didn't hear from any
David Sterba wrote:
On Fri, Jun 22, 2018 at 01:13:31AM +0200, waxhead wrote:
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
There are several WARN_ON calls that catch incrorrect reference counter
updates, but this is what the refcount_t does already:
* refcount_inc from 0 will warn
* refcount_dec_and_test from 0 will warn
Signed-off-by: David Sterba
---
fs/btrfs/delayed-ref.h | 1 -
fs/btrfs/extent_map.c | 2 +-
On 06/25/2018 06:07 PM, Marc MERLIN wrote:
> On Tue, Jun 19, 2018 at 12:58:44PM -0400, Austin S. Hemmelgarn wrote:
>>> In your situation, I would run "btrfs pause ", wait to hear from
>>> a btrfs developer, and not use the volume whatsoever in the meantime.
>> I would say this is probably good
On Mon, Jun 25, 2018 at 01:58:58PM +0900, Misono Tomohiro wrote:
> So, this is the updated version of
> https://patchwork.kernel.org/patch/10063039/
>
> This time xfstest is ok and
> Reviewed-by: Misono Tomohiro
Your comment about invalidate_mapping_pages is also ok, right? As
On Tue, Jun 19, 2018 at 12:58:44PM -0400, Austin S. Hemmelgarn wrote:
> > In your situation, I would run "btrfs pause ", wait to hear from
> > a btrfs developer, and not use the volume whatsoever in the meantime.
> I would say this is probably good advice. I don't really know what's going
> on
On Mon, Jun 25, 2018 at 11:24:50AM +0300, Nikolay Borisov wrote:
> Following the removal of the v0 handling code let's be courteous and
> print an error message when such extents are handled. In the cases
> where we have a transaction just abort it, otherwise just call
> btrfs_handle_fs_error.
On Sat, Jun 23, 2018 at 05:11:52AM +, Duncan wrote:
> > 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
On 25 Jun 2018, at 9:54, David Sterba wrote:
> On Mon, Jun 25, 2018 at 06:45:32AM -0700, Chris Mason wrote:
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 193f933..38403aa 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -9013,6 +9013,7 @@ vm_fault_t
On Mon, Jun 25, 2018 at 06:45:32AM -0700, Chris Mason wrote:
> The vm_fault_t conversion commit introduced a ret2 variable for
> tracking the integer return values from internal btrfs functions. It
> was sometimes returning VM_FAULT_LOCKED for pages that were actually
> invalid and had been
On 25 Jun 2018, at 7:10, David Sterba wrote:
On Fri, Jun 22, 2018 at 05:25:54PM -0400, Chris Mason wrote:
The bug came here:
commit a528a24150870c5c16cbbbec69dba7e992b08456
Author: Souptick Joarder
Date: Wed Jun 6 19:54:44 2018 +0530
btrfs: change return type of btrfs_page_mkwrite to
The vm_fault_t conversion commit introduced a ret2 variable for
tracking the integer return values from internal btrfs functions. It
was sometimes returning VM_FAULT_LOCKED for pages that were actually
invalid and had been removed from the radix. Something like this:
ret2 =
On Fri, Jun 22, 2018 at 01:13:31AM +0200, waxhead wrote:
> 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 light on
On 2018-06-24 16:22, Goffredo Baroncelli wrote:
On 06/23/2018 07:11 AM, Duncan wrote:
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
On Fri, Jun 22, 2018 at 05:25:54PM -0400, Chris Mason wrote:
> The bug came here:
>
> commit a528a24150870c5c16cbbbec69dba7e992b08456
> Author: Souptick Joarder
> Date: Wed Jun 6 19:54:44 2018 +0530
>
> btrfs: change return type of btrfs_page_mkwrite to vm_fault_t
>
> When page->mapping
On 20.06.2018 12:02, 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 extent with a special block_start value.
>
> Fixes: 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when fm_extent_count
>
On 25.06.2018 11:44, Nikolay Borisov wrote:
>
>
> On 23.06.2018 09:38, Chengguang Xu wrote:
>> Remove -ERANGE error check because there is no chance to get into
>> this condition and meanwhile avoid overriding errno to -EIO in
>> btrfs_get_acl().
>
> This is way too terse. The reason why we
On 23.06.2018 09:38, Chengguang Xu wrote:
> Remove -ERANGE error check because there is no chance to get into
> this condition and meanwhile avoid overriding errno to -EIO in
> btrfs_get_acl().
This is way too terse. The reason why we can't get an ERANGE error is
because we first call
The v0 compat code was introduced in commit 5d4f98a28c7d
("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9
years ago, which was merged in 2.6.31. This means that the code is
there to support filesystems which are _VERY_ old and if you are using
btrfs on such an old kernel, you
It's unlikely there is anyone using that or even if they are they have bigger
problems than this patchset :). After all, v0 was introduced 9 years ago and
it was already conditionally compiled by the time BTRFS was merged in the
upstream kernel. The patches themselves are really simple - patch 1
Following the removal of the v0 handling code let's be courteous and
print an error message when such extents are handled. In the cases
where we have a transaction just abort it, otherwise just call
btrfs_handle_fs_error. Both cases result in the FS being re-mounted RO.
Signed-off-by: Nikolay
29 matches
Mail list logo
