On 26.06.2018 09:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
Everytime I hear anything quota-related
On 06/20/2018 10:06 PM, 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 older fs_devices, then the
(sorry for the delay in reply due to my vacation and, other
urgent things took my priority too).
Please see inline below.
On 06/19/2018 09:53 PM, David Sterba wrote:
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:
There is no chance to get into -ERANGE error condition because
we first call btrfs_getxattr to get the length of the attribute,
then we do a subsequent call with the size from the first call.
Between the 2 calls the size shouldn't change. So remove the
unnecessary -ERANGE error check and meanwhile
Hello Nikolay,
I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
to fail correctly rescanning quota when quota is enabled.
Simple reproducer:
$ mkfs.btrfs -f $DEV
$ mount $DEV /mnt
$ dd if=/dev/urandom of=/mnt/file bs=
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 d
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 invalidate_ma
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 comme
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
> pa
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 kioc
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 don't
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 = btrfs_delalloc_re
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 peo
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 develope
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 l
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 +-
fs
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 advi
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
filemap_fdatawai
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 her
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. Both
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 s
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 btrfs_page_mkwri
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 remove
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 = btrfs_delallo
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 e
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 significan
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 c
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 btrfs_get
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 have
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 Bori
34 matches
Mail list logo
