On Tue, Oct 20, 2015 at 07:34:06PM +0800, Liu Bo wrote:
> Btrfs now has changed to delete subvolume/snapshot asynchronously,
> which means that after umount, if we've already deleted 'ext2_saved',
> rollback can still be completed, which should not.
>
> So this adds a regression test for this.
>
On Thu, Oct 22, 2015 at 1:42 AM, Qu Wenruo wrote:
> Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
> iteration.
>
> As extent buffer contains lock, pointers to pages, it's never sane to do
> such copy.
>
> The following bug may be caused by this insane operation:
> [92098
Hi!
I get this:
merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/mapper/sata-debian (id 1) history
scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:00:00
total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/dm-2 (id 2) histo
Filipe Manana wrote on 2015/10/22 09:16 +0100:
On Thu, Oct 22, 2015 at 1:42 AM, Qu Wenruo wrote:
Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
iteration.
As extent buffer contains lock, pointers to pages, it's never sane to do
such copy.
The following bug may be c
Kernel panic occurred due to NULL pointer reference in can_overcommit().
Because btrfs_async_reclaim_metadata_space() passed NULL pointer to
btrfs_calc_reclaim_metadata_size().
[ 3756.152833] BUG: unable to handle kernel NULL pointer der
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the delayed
references implementation in order to fix certain problems with qgroups.
However that rework introduced one more regression that leads to the
following trace when running delayed references for metadata:
On Thu, Oct 22, 2015 at 6:32 AM, Erkki Seppala wrote:
> Hello,
>
> Recently I added daily rebalancing to my cron.d (after finding myself in
> the no-space-situation), and not long after that, I found my PC had
> crashed over night. Having no sign in the logs anywhere (not even over
> network even
Enable the extended 'limit' syntax (a range), the new 'stripes' and
extended 'usage' syntax (a range) filters in the filters mask. The patch
comes separate and not within the series that introduced the new filters
because the patch adding the mask was merged in a late rc. The
integration branch was
wrote on 2015/10/22 09:47 +0100:
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the delayed
references implementation in order to fix certain problems with qgroups.
However that rework introduced one more regression that leads to the
following trace when ru
On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo wrote:
>
>
> wrote on 2015/10/22 09:47 +0100:
>>
>> From: Filipe Manana
>>
>> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
>> references implementation in order to fix certain problems with qgroups.
>> However that rework i
On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana wrote:
> On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo wrote:
>>
>>
>> wrote on 2015/10/22 09:47 +0100:
>>>
>>> From: Filipe Manana
>>>
>>> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
>>> references implementation in or
Op 22-10-15 om 10:47 schreef fdman...@kernel.org:
> From: Filipe Manana
>
> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
> references implementation in order to fix certain problems with qgroups.
> However that rework introduced one more regression that leads to the
>
Le 2015-10-22 10:53, Filipe Manana a écrit :
On Thu, Oct 22, 2015 at 6:32 AM, Erkki Seppala
wrote:
Hello,
Recently I added daily rebalancing to my cron.d (after finding myself
in
the no-space-situation), and not long after that, I found my PC had
crashed over night. Having no sign in the log
在 2015年10月22日 17:43, Filipe Manana 写道:
On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo wrote:
wrote on 2015/10/22 09:47 +0100:
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the delayed
references implementation in order to fix certain problems with qgro
On Thu, Oct 22, 2015 at 11:05 AM, Koen Kooi wrote:
> Op 22-10-15 om 10:47 schreef fdman...@kernel.org:
>> From: Filipe Manana
>>
>> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
>> references implementation in order to fix certain problems with qgroups.
>> However that
Le 2015-10-22 11:47, Filipe Manana a écrit :
On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana
wrote:
On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo
wrote:
wrote on 2015/10/22 09:47 +0100:
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the
delayed
referen
Hello,
Thanks for the super-fast response :).
I've installed the patch and shall be waiting. The effects should be
visible within a week given daily rebalances of two filesystems.
--
_
/ __// /__ __ h
On Thu, Oct 22, 2015 at 3:58 PM, Stéphane Lesimple
wrote:
> Le 2015-10-22 11:47, Filipe Manana a écrit :
>>
>> On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana
>> wrote:
>>>
>>> On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo
>>> wrote:
wrote on 2015/10/22 09:47 +0100:
>
On Sun, Oct 18, 2015 at 07:41:27PM +0800, Qu Wenruo wrote:
> 在 2015年10月18日 13:44, Liu Bo 写道:
> > Btrfs has changed to delete subvolume/snapshot asynchronously, which means
> > that
> > after umount itself, if we've already deleted 'ext2_saved', rollback can
> > still
> > be completed.
> >
> > So
Le 2015-10-22 19:03, Filipe Manana a écrit :
On Thu, Oct 22, 2015 at 3:58 PM, Stéphane Lesimple
wrote:
Le 2015-10-22 11:47, Filipe Manana a écrit :
On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana
wrote:
On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo
wrote:
wrote on 2015/10/22 09:47 +0
We hit this panic on a few of our boxes this week where we have an
ordered_extent with an NULL inode. We do an igrab() of the inode in writepages,
but weren't doing it in writepage which can be called directly from the VM on
dirty pages. If the inode has been unlinked then we could have I_FREEING
I'm having a weird problem with snapshots and exclusive quotas. After
creating a snapshot of a subvolume and setting an exclusive quota of
50MB for the snapshot, everything seems to work fine. I can write
approximately 50MB before the quota kicks in.
However, if I create a snapshot, set an exclusi
[ ... thread cleanup ... ]
Don't hesitate to ask if you need me to debug or even ftrace
something.
Thanks Stéphane. I haven't seen that crash yet (still running tests
for 2 consecutive days now).
Can you please try the following patch, which works on top of mine,
and enable ftrace before runnin
On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple
wrote:
[ ... thread cleanup ... ]
Don't hesitate to ask if you need me to debug or even ftrace something.
>>>
>>>
>>> Thanks Stéphane. I haven't seen that crash yet (still running tests
>>> for 2 consecutive days now).
>>> Can you
Hi again,
So I intentionally broke this small raid6 fs on a VM to learn recovery
strategies for another much bigger raid6 I have running (which also
suffered a drive failure).
Basically I zeroed out one of the drives (vdd) from under the running
vm. Then ran an md5sum on a file on the fs to
在 2015年10月23日 04:38, Johannes Henninger 写道:
I'm having a weird problem with snapshots and exclusive quotas. After
creating a snapshot of a subvolume and setting an exclusive quota of
50MB for the snapshot, everything seems to work fine. I can write
approximately 50MB before the quota kicks in.
On Tue, Oct 20, 2015 at 04:29:46PM +0300, Timofey Titovets wrote:
> For performance reason, leave data at the start of disk, is preferable
> while deduping
> It's might sense for the reasons:
> 1. Spinning rust - start of the disk is much faster
> 2. Btrfs can deallocate empty data chunk from the e
Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
iteration.
As extent buffer contains lock, pointers to pages, it's never sane to do
such copy.
The following bug may be caused by this insane operation:
[92098.841309] general protection fault: [#1] SMP
[92098.841338] M
On 10/23/2015 03:05 AM, Josef Bacik wrote:
We hit this panic on a few of our boxes this week where we have an
ordered_extent with an NULL inode. We do an igrab() of the inode in writepages,
but weren't doing it in writepage which can be called directly from the VM on
dirty pages. If the inode h
29 matches
Mail list logo
