Am Donnerstag, 24. Juli 2014, 16:04:22 schrieb Chris Mason:
> On 07/24/2014 02:49 PM, Martin Steigerwald wrote:
> > Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
> >> On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
> >>> Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
> >>>> Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
> >>>>> On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
> >>>>>> Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
> >>>>>>> On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
> >>>>>>>> Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
> >>>>>>>>> Hi!
> >>>>>>>>>
> >>>>>>>>> While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several
> >>>>>>>>> days
> >>>>>>>>> of
> >>>>>>>>> usage, with 3-16-rc5 I had a hang again. Less than a hour since
> >>>>>>>>> booting
> >>>>>>>>> it.
> >>>>>>>>>
> >>>>>>>>> Since the hang bug I and others had with 3.15 and upto 3.16-rc2
> >>>>>>>>> usually
> >>>>>>>>> didn´t happen that quickly after boot and since backtrace looks a
> >>>>>>>>> bit
> >>>>>>>>> different from what I have in memory, I post this in a new thread.
> >>>>>>>>> See thread "Blocked tasks on 3.15.1" for a discussion of previous
> >>>>>>>>> hang
> >>>>>>>>> issues.
> >>>>>>>>
> >>>>>>>> Probably good to add some basic information on the filesystem:
> >>>>>>> Do you have compression enabled? I wasn't able to nail down the
> >>>>>>> 3.15.1
> >>>>>>> hang before vacation attacked me, but I'm hoping to track it down
> >>>>>>> today.
> >>>>>>
> >>>>>> Yes. I have.
> >>>>>>
> >>>>>> It just hung again while I was playing PlaneShift.
> >>>>>>
> >>>>>> Back to 3.16-rc4 as rc5 seems to be broke here.
> >>>>>
> >>>>> The btrfs hang you're hitting goes back to 3.15. So 3.16-rc4 vs rc5
> >>>>> shouldn't be a factor. Are you hitting other problems with 3.16?
> >>>>
> >>>> So far for this day 3.16-rc4 behaves nicely. With 3.16-rc5 I had a
> >>>> BTRFS
> >>>> hang twice yesterday. 3.16-rc4 before also behaved nicely for several
> >>>> days
> >>>> or well about a week here.
> >>>
> >>> 3.16-rc4 now hung as well…
> >>
> >> Liu Bo has a promising patch:
> >>
> >> https://urldefense.proofpoint.com/v1/url?u=https://patchwork.kernel.org/p
> >> atch/4618421/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=6%2FL0lzzDhu0Y1hL9xm%2B
> >> QyA%3D%3D%0A&m=CJPREifRDOxlzhYeURx75h33LGU7YemJsNeLP%2FvXCv8%3D%0A&s=8fb0
> >> a70afce09530f16ea66a47d2af07966706b21281a7142d86256979013bab
> >>
> >> Please give it a shot. There's a second deadlock reading the free space
> >> cache, I'm still working on that one too.
> >
> > Now running 3.16-rc6 + current git + this patch.
> >
> > It may take some time tough cause during compiling the kernel BTRFS hung
> > again, which caused loss of KDE Baloo desktop search file index and parts
> > of a mail I wrote in KMail.
> >
> > Since the patch mentioned ENOSPC issues but the filesystem has enough free
> > space according to df I shrunk the trees with
>
> Thanks for giving it a try. The ENOSPC mentioned here is looking for a
> contiguous extent, so it's easily possible to trigger that enospc
> without actually being full.
So far no lockup with 3.16.0-rc6-tp520-fixcompwrite+
But BTRFS still not used up all space for laying out trees after balance:
Label: 'home' uuid: […]
Total devices 2 FS bytes used 126.70GiB
devid 1 size 160.00GiB used 156.00GiB path /dev/dm-0
devid 2 size 160.00GiB used 156.00GiB path /dev/mapper/sata-home
May be a good sign nonetheless, thus mentioned.
Any other findings?
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
