On Tue, Aug 12, 2014 at 10:55:51AM +0800, Miao Xie wrote:
> On Sun, 10 Aug 2014 22:55:44 +0800, Liu Bo wrote:
> > This part of the trace is relatively new because Liu Bo's patch made us
> > redirty the pages, making it more likely that we'd try to write them
> > during commit.
> >
>
On Sun, 10 Aug 2014 22:55:44 +0800, Liu Bo wrote:
> This part of the trace is relatively new because Liu Bo's patch made us
> redirty the pages, making it more likely that we'd try to write them
> during commit.
>
> But, at the end of the day we have a fundamental deadlock with
On 08/10/2014 10:55 AM, Liu Bo wrote:
> On Thu, Aug 07, 2014 at 10:02:15AM -0400, Chris Mason wrote:
>>
>>
>> On 08/07/2014 04:20 AM, Miao Xie wrote:
>>> On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
>> [90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
>> 0x
>
On Thu, Aug 07, 2014 at 10:02:15AM -0400, Chris Mason wrote:
>
>
> On 08/07/2014 04:20 AM, Miao Xie wrote:
> > On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
> [90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
> 0x
> [90496.157683] Workqueue: btrfs-del
On 08/07/2014 04:20 AM, Miao Xie wrote:
> On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
[90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
0x
[90496.157683] Workqueue: btrfs-delalloc normal_work_helper [btrfs]
[90496.159320] 88022880f990
On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
>>> [90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
>>> 0x
>>> [90496.157683] Workqueue: btrfs-delalloc normal_work_helper [btrfs]
>>> [90496.159320] 88022880f990 0002 880407f649b0
>>> 88022880f
Hi,
On Wed, Aug 06, 2014 at 08:52:41PM -0400, Chris Mason wrote:
> On 08/06/2014 11:18 AM, Chris Mason wrote:
> > On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
> >> Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
> >>> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
> > I thin
On 08/06/2014 11:18 AM, Chris Mason wrote:
> On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
>> Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
>>> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
> I think this should go to stable. Thanks, Liu.
>>>
>>> I'm definitely tagging this
On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
> Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
>> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
I think this should go to stable. Thanks, Liu.
>>
>> I'm definitely tagging this for stable.
>>
>>> Unfortunately this fix does no
Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
> On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
> >> I think this should go to stable. Thanks, Liu.
>
> I'm definitely tagging this for stable.
>
> > Unfortunately this fix does not seem to fix all lockups.
>
> The traces below are a
On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
>> I think this should go to stable. Thanks, Liu.
I'm definitely tagging this for stable.
>
> Unfortunately this fix does not seem to fix all lockups.
The traces below are a little different, could you please send the whole
file?
-chris
>
>
Am Mittwoch, 6. August 2014, 11:29:19 schrieb Hugo Mills:
> On Wed, Aug 06, 2014 at 12:21:59PM +0200, Martin Steigerwald wrote:
> > It basically happened on about the first heavy write I/O occasion after
> > the BTRFS trees filled the complete device:
> >
> > I am now balancing the trees down to l
On Wed, Aug 06, 2014 at 12:21:59PM +0200, Martin Steigerwald wrote:
> It basically happened on about the first heavy write I/O occasion after
> the BTRFS trees filled the complete device:
>
> I am now balancing the trees down to lower sizes manually with
>
> btrfs balance start -dusage=10 /home
>
Am Montag, 4. August 2014, 14:50:29 schrieb Martin Steigerwald:
> Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> > Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > > When failing to allocate space for the whole compressed extent, we'll
> > > fallback to uncompressed IO,
Am Montag, 4. August 2014, 14:50:29 schrieb Martin Steigerwald:
> Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> > Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > > When failing to allocate space for the whole compressed extent, we'll
> > > fallback to uncompressed IO,
Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
> Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> > When failing to allocate space for the whole compressed extent, we'll
> > fallback to uncompressed IO, but we've forgotten to redirty the pages
> > which belong to this compre
Am Freitag, 25. Juli 2014, 09:00:19 schrieb Liu Bo:
> On Thu, Jul 24, 2014 at 10:55:47AM -0400, Chris Mason wrote:
> > On 07/24/2014 10:48 AM, Liu Bo wrote:
> > > When failing to allocate space for the whole compressed extent, we'll
> > > fallback to uncompressed IO, but we've forgotten to redirty
Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
> When failing to allocate space for the whole compressed extent, we'll
> fallback to uncompressed IO, but we've forgotten to redirty the pages
> which belong to this compressed extent, and these 'clean' pages will
> simply skip 'submit' part an
On 07/25/2014 10:08 AM, Liu Bo wrote:
On Fri, Jul 25, 2014 at 09:53:43AM +0800, Wang Shilong wrote:
On 07/24/2014 10:48 PM, Liu Bo wrote:
When failing to allocate space for the whole compressed extent, we'll
fallback to uncompressed IO, but we've forgotten to redirty the pages
which belong to t
On Fri, Jul 25, 2014 at 09:53:43AM +0800, Wang Shilong wrote:
> On 07/24/2014 10:48 PM, Liu Bo wrote:
> >When failing to allocate space for the whole compressed extent, we'll
> >fallback to uncompressed IO, but we've forgotten to redirty the pages
> >which belong to this compressed extent, and thes
On 07/24/2014 10:48 PM, Liu Bo wrote:
When failing to allocate space for the whole compressed extent, we'll
fallback to uncompressed IO, but we've forgotten to redirty the pages
which belong to this compressed extent, and these 'clean' pages will
simply skip 'submit' part and go to endio directly
On Thu, Jul 24, 2014 at 10:55:47AM -0400, Chris Mason wrote:
> On 07/24/2014 10:48 AM, Liu Bo wrote:
> > When failing to allocate space for the whole compressed extent, we'll
> > fallback to uncompressed IO, but we've forgotten to redirty the pages
> > which belong to this compressed extent, and th
On 07/24/2014 10:48 AM, Liu Bo wrote:
> When failing to allocate space for the whole compressed extent, we'll
> fallback to uncompressed IO, but we've forgotten to redirty the pages
> which belong to this compressed extent, and these 'clean' pages will
> simply skip 'submit' part and go to endio di
When failing to allocate space for the whole compressed extent, we'll
fallback to uncompressed IO, but we've forgotten to redirty the pages
which belong to this compressed extent, and these 'clean' pages will
simply skip 'submit' part and go to endio directly, at last we got data
corruption as we w
24 matches
Mail list logo
