Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Feb 2015 19:03:57 +0900
From:      "Lundberg, Johannes" <johannes@brilliantservice.co.jp>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org>, Dimitry Andric <dim@freebsd.org>, Allan Jude <allanjude@freebsd.org>
Subject:   Re: Weird behavior writing to SSD on 2013 MacBook
Message-ID:  <CAASDrVksB%2B_a2RfM7ZjkvkmMD_V%2BZ13o=ZHcTqygEOGBqmeR7w@mail.gmail.com>
In-Reply-To: <D0C3024E-FEE9-486F-AEAE-F66720A86FC3@mu.org>
References:  <CAASDrV=d=7aGdsDzDxRS2aXW%2BtWijVmNWrCNSYLWrWWvgwYx6Q@mail.gmail.com> <54D2C3DA.4060205@freebsd.org> <CAASDrV=9zrG8mH0Cn770yJLG6cBxuFjBQthhcHB_q4e7Afthww@mail.gmail.com> <CAASDrVnY8RQV2C=k=_v=23VD%2BQcXYegm1SLQPXDULwfQQ1xsDA@mail.gmail.com> <54D319EA.5020709@freebsd.org> <CAASDrVmcOzQiNMhi5dukd4PEyGXV4_T71jh3E3DfaWjKWWWM6g@mail.gmail.com> <AF0781EF-50BD-4CAB-8FEC-6334EED6DACF@FreeBSD.org> <20150205083035.GF42409@kib.kiev.ua> <54D32DC3.6020409@mu.org> <20150205090324.GI42409@kib.kiev.ua> <D0C3024E-FEE9-486F-AEAE-F66720A86FC3@mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
It seems like the patch solved my problem. No more freezing of the
filesystem.


--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.

On Thu, Feb 5, 2015 at 6:19 PM, Alfred Perlstein <bright@mu.org> wrote:

> It's possible original intent of that construct was just a pause/throttle
> if it used to be an if(). Makes sense although should investigate further=
.
>
> Sent from my iPhone
>
> > On Feb 5, 2015, at 1:03 AM, Konstantin Belousov <kostikbel@gmail.com>
> wrote:
> >
> >> On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote:
> >>
> >>
> >>> On 2/5/15 12:30 AM, Konstantin Belousov wrote:
> >>>> On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote:
> >>>> If you let bsdtar continue, and press control-T a few times, does th=
e
> >>>> user time (u) increase at all?  Does it ever go any further, if you
> let
> >>>> it run for a very long time?
> >>>>
> >>>> I believe a problem may have been introduced by r277922, leading to
> >>>> filesystem hangs in some scenarios.  It looks like this commit is al=
so
> >>>> in dumbbell's github fork:
> >>>>
> >>>>
> https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81=
086899f521
> >>>
> >>> Would be nice if you mailed me with your findings.
> >>>
> >>> Please try this.
> >>>
> >>> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
> >>> index 79783c8..700854e 100644
> >>> --- a/sys/ufs/ffs/ffs_softdep.c
> >>> +++ b/sys/ufs/ffs/ffs_softdep.c
> >>> @@ -1393,7 +1393,7 @@ softdep_flush(addr)
> >>>              VFSTOUFS(mp)->softdep_jblocks->jb_suspended))
> >>>              kthread_suspend_check();
> >>>          ACQUIRE_LOCK(ump);
> >>> -        while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =
=3D=3D
> 0)
> >>> +        if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=
=3D 0)
> >>>              msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM,
> >>>                  "sdflush", hz / 2);
> >>>          ump->softdep_flags &=3D ~FLUSH_CLEANUP;
> >>> @@ -1423,10 +1423,9 @@ worklist_speedup(mp)
> >>>
> >>>      ump =3D VFSTOUFS(mp);
> >>>      LOCK_OWNED(ump);
> >>> -    if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0=
) {
> >>> +    if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0=
)
> >>>          ump->softdep_flags |=3D FLUSH_CLEANUP;
> >>> -        wakeup(&ump->softdep_flushtd);
> >>> -    }
> >>> +    wakeup(&ump->softdep_flushtd);
> >>>  }
> >>>
> >>>  static int
> >>> @@ -1471,11 +1470,10 @@ softdep_speedup(ump)
> >>>              TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next);
> >>>              FREE_GBLLOCK(&lk);
> >>>              if ((altump->softdep_flags &
> >>> -                (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) {
> >>> +                (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0)
> >>>                  altump->softdep_flags |=3D FLUSH_CLEANUP;
> >>> -                altump->um_softdep->sd_cleanups++;
> >>> -                wakeup(&altump->softdep_flushtd);
> >>> -            }
> >>> +            altump->um_softdep->sd_cleanups++;
> >>> +            wakeup(&altump->softdep_flushtd);
> >>>              FREE_LOCK(altump);
> >>>          }
> >>>      }
> >>> _______________________________________________
> >>
> >> Why the conversion of while() to if()?
> >>
> >>
> >> The reason for a while() when doing msleep/wakeup is typically to
> >> prevent superfluous wakeups from signalling early.
> >
> > if()->while() was one of the changes in r277922, and I suspect that it
> > is the cause of the issue.  I.e. my thought right now is that
> > softdep_process_worklist() does not keep up with the requests.
> >
> > If this is true, then real fix is somewhere else, but restoring
> > pre-r277922 behaviour should get rid of immediate pain.
> >
>

--=20
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
=E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF=
=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=
=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97=
=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5=
=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82=
=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE=
=E3=81=99=E3=80=82
=E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=
=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=
=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE=
=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3=
=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88=
=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81
=E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4=
=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8=
=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84=
=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3=
=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=
=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASDrVksB%2B_a2RfM7ZjkvkmMD_V%2BZ13o=ZHcTqygEOGBqmeR7w>